On Fri, 4 Apr 2025 15:22:10 GMT, Severin Gehwolf <sgehw...@openjdk.org> wrote:
>> For JEP 493-enabled builds there are no JMODs. Certain files come from the >> installed JDK image when a user creates a custom run-time from it. This is >> problematic for example for files that often come from a different package >> (e.g. `cacerts` file for Linux distro builds of OpenJDK packaged as RPMs), >> or more generally when they get updated out-of-band of the JDK build itself >> like the tzupdater tool. >> >> When that happens the hash sum recorded at JDK build time of those files no >> longer match, causing `jlink` to fail. I propose to allow for those files to >> get "upgraded" should this happen. The way this works is as follows: >> >> 1. The list of upgradeable files is configured by a resource file in >> `jdk.jlink` on a per module basis. Right now, only two files from the >> `java.base` module will be allowed to be upgraded with a link from the >> current run-time image. >> 2. For those files the hash sum checks are skipped. >> >> **Testing** >> >> - [x] GHA >> - [x] `jdk/tools/jlink` jtreg tests >> - [x] Some manual tests with updated `tzdb.dat` and `cacerts` files. >> >> Thoughts? > > Severin Gehwolf has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains four additional > commits since the last revision: > > - Reboot upgradeable files approach > - Revert "8353185: Introduce the concept of upgradeable files in context of > JEP 493" > > This reverts commit bfbfbcb8212ed0f9825549b02b4b52e930c379a7. > - Merge branch 'master' into jdk-8353185-upgradable-files-jep493 > - 8353185: Introduce the concept of upgradeable files in context of JEP 493 It took me a while to find the magic trick to get the jlink resource file copied, so adding build-dev for their input too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24388#issuecomment-2779101393
