RFR: 8353185: Introduce the concept of upgradeable files in context of JEP 493

[Severin Gehwolf]

On Thu, 3 Apr 2025 09:46:38 GMT, Alan Bateman <alanb at 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