On Mon, 10 Nov 2025 16:32:41 GMT, Henry Jen <[email protected]> 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
