On Mon, 10 Nov 2025 16:45:51 GMT, Alan Bateman <[email protected]> wrote:
>>> 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.
For target java.base not having release.txt will show mismatch against build
"N/A". But I am thinking I will tighten it up to avoid current release.txt is
have a value "N/A".
What I am talking about is should we fail gracefully on current java.base for
jlink not having a release.txt, which should not happen with a proper build. In
that sense, an IllegalArgumentException is not that bad.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2511460040
