JEP 493 new in JDK 24 allows for linking from the run-time image. In such a mode resources for the resulting image come from two sources 1) the lib/modules image for classes and resource and 2) the installed JDK image for certain other artefacts (like libraries, binaries, configuration files). In order to prevent accidental population of configuration file changes in the current run-time image to the resulting runtime, JEP 493 introduces hash sum checks so as to ensure that files taken as input haven't been changed to the version that are in the JMODs (note: JMODs serve as the baseline for hash sums; files in JMODs are used to compute the hash sum, then compared at run-time image link time to the file present on the filesystem).

A corollary of this is that the JDK image cannot change after it has been linked at build time. All resources need to be the same as they were at link time. This assumption, however, doesn't necessarily hold. We know of at least two cases where this wouldn't be the case.

The first case is JDK-8351842 affecting Windows when the build is configured with --with-external-symbols-in-bundles=public. In such a scenario the Windows *.pdb files as installed in the JDK image, don't correspond to the *.pdb files present at link-time. After the JDK image has been linked, *.pdb files get replaced with the ones including full debug symbols (in contrast to stripped *.pdb files in JMODs used at link-time). The second issue we are aware of are JDK builds done by rpmbuild (RPMs) in Fedora/RHEL. Fedora/RHEL has a system of expecting debug symbols to be present in the binary itself. Those symbols are then being extracted into separate debuginfo packages as the very last step of the RPM build. In the JDK case, this means the jlink invocation at JDK build time happens at time A, but the post-processing of the binaries to extract debug symbols happens at time A+N for some value of N > 1. Note that this happens even after the JDK build itself has done its post-processing as described in the first problematic Windows case. As such, at time A+N the hash sum of the JDK binaries and libraries would have to be calculated and, in retrospect, changed in the modules image to have the actual value present in the JDK image.

Both those cases suggest that there needs to be a way to provide hash sums of certain files independent of the JDK build itself.