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

[Severin Gehwolf]

On Tue, 2024-10-22 at 10:10 -0700, Alex Buckley wrote:
> 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`

It's a good point. I believe `jlink --help` having this reporting would
be a nice addition.

> I have to actually do some
> linking. It would be helpful if the JEP said this plainly in the 
> Description.

Makes sense.

> > > 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."

I'll add it.

> > > 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.

OK.

Thanks,
Severin