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
