[External] : Re: New candidate JEP: 493: Linking Run-Time Images without JMODs

[Alex Buckley]

On 10/22/2024 2:17 AM, Severin Gehwolf wrote:
> Using --verbose will show this for a run-time image link:
> 
> """
>      $ ./runtime-image-link-jdk/bin/jlink --add-modules java.base \
>                  --output ./java.base-from-run-time --verbose
>      Linking based on the current run-time image.
>      java.base jrt:/java.base (run-time image)
...
> Conversely, if JMODs are present - for a build with
> --enable-linkable-runtime - the verbose output looks as before:
> 
> """
>      $ ./jdk/bin/jlink --add-modules java.base \
>                  --output ./java.base-from-jmods --verbose
>      java.base file:///path/to/jdk/jmods/java.base.jmod
...
> I.e. it tells the user where it is taking the bits from (JMODs or run-
> time image).
> 
> I'm happy to expand the JEP with this detail, but this would be for
> expert users and not exactly the intended target audience of JEP
> readers. It's not clear if it'll confuse readers of the JEP or provides
> clarity.

In no way is this a "detail" for expert users. If I have a JDK on my 
machine, perhaps provided by my employer or my school, I want to be able 
to find out if the jlink in that JDK can link from just JMODs or from 
<<JMODs + run-time images>>. It's a basic question about the 
functionality of the jlink on my machine. It seems that I can't get the 
answer by simply running `jlink --help` -- I have to actually do some 
linking. It would be helpful if the JEP said this plainly in the 
Description.

>> I am also not crystal clear whether jlink in a JDK built with
>> --enable-linkable-runtime is capable of consuming run-time images _and_
>> JMODs, or just run-time images.
> 
> Both. As answered before, if the java.base module is specified on the
> module path (or the default module path has JMODs - `$JDK/jmods`) then
> it will try to use the java.base.jmod from there. Again, --verbose will
> show this distinction. Only if none of the other options are available
> it will link from the run-time image.

The JEP needs to explain this JMODs-win policy:  "A version of jlink 
that can consume both JMODs and run-time images always prefers to 
consume a module from a JMOD on the module path if available. Only if 
such a module is not found does jlink consume the module from the 
run-time image of which jlink is part."

>> As an editorial note, this text can't be true: "The jlink tool in the
>> resulting JDK works exactly the same way as the jlink tool in a JDK
>> built with the default configuration." -- the jlink tool in the
>> resulting JDK will extract from the run-time image, not from JMOD files,
>> so it's not working "exactly the same way". I think you mean that
>> _running_ the jlink tool in the resulting JDK is done in exactly the
>> same way.
> 
> Makes sense. How about this?
> 
> """
> Invoking the jlink tool in the resulting JDK works exactly the same way
> as the jlink tool in a JDK built with the default configuration.
> """

This still suggests that the _effect_ of invoking jlink in the resulting 
JDK is the same ("works exactly the same way") as invoking jlink in the 
default configuration. In fact, the effect is different. The thing that 
is the same is the _user experience_ -- what operands they give to jlink 
on the command line.

Alex