New candidate JEP: 493: Linking Run-Time Images without JMODs

[Severin Gehwolf]

Hi Alex,

Thanks for your input!

On Mon, 2024-10-21 at 11:19 -0700, Alex Buckley wrote:
> On 10/21/2024 9:14 AM, Mark Reinhold wrote:
> > https://openjdk.org/jeps/493
> 
> I was surprised to learn that the jlink tool which can link from a 
> run-time image is only available in a JDK built with 
> --enable-linkable-runtime. As a user, can I tell if the jlink tool in my 
> installed JDK consumes JMODs or consumes run-time images?

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

    Providers:
      java.base provides java.nio.file.spi.FileSystemProvider used by java.base
"""

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

    Providers:
      java.base provides java.nio.file.spi.FileSystemProvider used by java.base
"""

I.e. it tells the user where it is taking the bits from (JMODs or run-
time image). An earlier incarnation of the JEP did have this output
always enabled when performing a link from the run-time image:

    $ jlink --add-modules java.xml --output myimage
    Linking based on the current run-time image.

Based on previous feedback, we chose not to print this to stdout by
default since that might break some users who parse jlink output.

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.

The associated CSR will have those details.

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

> If it can consume run-time images _and_ JMODs, which origin is preferred 
> when resolving modules passed to --add-modules?

JMODs are preferred.

> Can it consume only the run-time image it was built as a part of, or can 
> I point --module-path to other run-time images? (presumably built with 
> --enable-linkable-runtime themselves)

Right now, only the run-time image it was built as a part of.

> It would be good if the JEP could clarify these points for all readers.

OK, thanks. I'll confer with previous reviewers and will work on an
update to clarify this.

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

Thanks,
Severin