On Thu, 3 Apr 2025 09:46:38 GMT, Alan Bateman <al...@openjdk.org> wrote:
> Part of me is concerned that the hidden option is a bit of an attractive > nuisance. What would you think about just having a fixed list in a properties > file in the repo, thus a resource in the jlink module. This would avoid the > list in JRTArchive too. It wouldn't rule out introducing something more in > the future. I'm not entirely sure what you are suggesting. Is it keeping a list of "upgradeable" files in a properties file. Files listed in that properties file aren't checked for hash sums (i.e. even if it's not modified)? That is, the explicit opt-in is not needed? Fine by me, but it's a weaker check. If we don't need the explicit opt-in, the patch becomes simpler as well. > Right now the only examples we have are in java.base. In time it might be > that some other modules might need something. Sure. I've considered that. The `java.base` specific check can go away and it should work for any module as long as we have a list of what's considered an upgradable file (wherever it comes from). > I've like to know more about cacerts. Are the distros swapping this to a link > after the run-time image is created or is it that the sym link is there from > the startup and the hashing has followed the link? Yes, that's one case. For example Fedora/RHEL distros have a `ca-certificates` package which also provides a `cacerts` file consumable from the JDK (`/etc/pki/java/cacerts`). This can be a build-time option, or replaced with a symlink after the JDK has been built. Another use case is amending the cacerts store. For example with an enterprise internal CA, in a container. It's really not different to `tzdb.dat`. That too, can be a symlink to a system package or get updated with an external tool after a build. The option of not following symlinks, isn't an option, though, as certain distro packaging standards require one to install, say man pages - in a specific directory. To keep the JDK image whole, that is usually fixed by placing a symlink back in the JDK image directory. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2775258217
