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

[Alex Buckley]

On 10/22/2024 2:03 AM, Alan Bateman wrote:
> As a user, the JDK you download may contain a "jmods" directory, it may 
> not. This should just work:
> 
>      $JDK/bin/jlink --add-modules java.se --output myjdk
> 
> It doesn't matter if jlink uses packaged modules in $JDK/jmods or 
> reconstitutes the module content from $JDK run-time image by other 
> means. 

There is no Goal that communicates: "Allow users to link a run-time 
image from modules on their machine without regard for whether those 
modules exist as standalone JMOD files or exist in a run-time image 
linked previously."

> Every jlink in every JDK build can consume JMOD files. 

It would be helpful to state this. And then: "In addition, in some JDK 
installations, jlink can consume modules from the run-time image of 
which it is part. Whether jlink can do this depends on how its run-time 
image was built."

> jlink support for using the packaged modules in another JDK is very 
> limited. You can do this today:
> 
>    $JDK1/bin/jlink --module-path $JDK2/jmods --add-modules java.se -- 
> output myjdk
> 
> but only if $JDK1 and $JDK2 are the same version, otherwise you get an 
> error like "Error: jlink version 24.0 does not match target java.base 
> version 22.0".

I might have a variety of run-time images installed on my (say) Windows 
machine, so it would be convenient if I could consume modules from one 
or more of those images when building a new run-time image -- I wouldn't 
need to ask anyone for JMOD files. This scenario is completely unrelated 
to cross-platform linking.

I see now that this scenario is not supported because I can't point 
--module-path to another run-time image, only to a location of JMODs. It 
would be helpful if the JEP stated this plainly, rather than expecting 
readers to know everything about jlink and then apply an "Unchanged 
unless we say otherwise" filter.

Alex