RFR: 8347831: Re-examine version check when cross linking [v2]

[Alan Bateman]

On Mon, 10 Nov 2025 16:32:41 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> 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.
>
>> 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?
> 
> Yes, that's same behavior as before. I agree jlink should handle java.base not in the module path gracefully, I will add another error message to handle that. Do we want that for target release.txt as well? Since that's currently throwing IllegalArgumentException.

I think this is an err.jlink.version.mismatch, of sorts, case. The user has run the jlink command with a module path containing a version of java.base that is at least one feature release old. I think a mismatch would be less confusing than an IllegalArgumentException.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2511266937