RFR: 8347831: Re-examine version check when cross linking [v2]
Alan Bateman
alanb at openjdk.org
Sat Nov 8 07:13:03 UTC 2025
On Fri, 7 Nov 2025 16:43:48 GMT, Henry Jen <henryjen at openjdk.org> wrote:
>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 600:
>>
>>> 598: ModuleReference target = finder.find("java.base").get();
>>> 599: String currentRelease = getReleaseInfo(current).orElseThrow(() ->
>>> 600: new IllegalArgumentException("Cannot find release.txt"));
>>
>> I assume this is an err.jlink.version.mismatch case too. The packaged version of java.base on the module path is missing the resource file so it must be an older version, hence a mismatch.
>
> This is for the current runtime of jlink, so this should never happen?
That's right. If getReleaseInfo(current) were to fail then it suggests a JDK build or other bug.
For the target runtime then finder.find("java.base") returning emptymeans the module path specified to jlink doesn't have java.base so this should be handled gracefully. With the current changes then it looks like it will fail up with NoSuchElementException, do I read this correctly?
If java.base is found on the module path but it doesn't contain the release file then the updated code to use "N/A" is okay as it feeds into the error message that jlink will print.
So I think the changes are nearly there.
I've added the "csr" label to the PR as this change will need a CSR. There may be cases today that are cross linking successfully (they got lucky) but they will fail with the change due to the stricter check.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2506343704
More information about the core-libs-dev
mailing list