RFR: 8347831: Re-examine version check when cross linking [v5]
Severin Gehwolf
sgehwolf at openjdk.org
Tue Nov 11 17:59:05 UTC 2025
On Tue, 11 Nov 2025 17:25:43 GMT, Henry Jen <henryjen at openjdk.org> wrote:
>> This PR include build changes from @magicus and jlink change to verify the build signature.
>>
>> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message.
>>
>> ❯ export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home
>>
>> ❯ java --version
>> openjdk 26-internal 2026-03-17
>> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831)
>> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing)
>>
>> ❯ jlink --version
>> 26-internal
>>
>> ❯ jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux
>>
>> ❯ jlink --add-modules java.base --output macos
>>
>> ❯ jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>>
>> ❯ jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25
>> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>
> Treat missing release.txt as emptry release signature
I think this can be tested akin to `JLinkOptionsTest` by implementing a simple plugin that transforms the `release.txt` resource and uses `--keep-packaged-modules` and then attempts to perform a link on the resulting image. Similarly we could cover the case of `release.txt` missing by using the `--exclude-resources` plugin.
src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 620:
> 618: // silently ignore and fall through to version mismatch
> 619: targetRelease = "";
> 620: }
You could avoid the NSEE and try/catch by handling that case explicitly:
Suggestion:
targetRelease = getReleaseInfo(target).orElseThrow(()-> new IllegalArgumentException("handle missing release.txt file"));
if (currentRelease.equals(targetRelease)) {
return;
}
-------------
PR Review: https://git.openjdk.org/jdk/pull/28155#pullrequestreview-3449192405
PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2515101026
More information about the build-dev
mailing list