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
