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
