RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v8]

Mandy Chung mchung at openjdk.org
Wed Nov 15 22:36:32 UTC 2023


On Wed, 15 Nov 2023 21:21:07 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Note that plugins like `--add-options` have been modified so that only the options passed at the current CLI will propagate to the final image. So in this case, `image1` would have property `com.foo.XYZ` set, but not `image2`. Incidentally, what you probably intended to use was `--add-options "-Dcom.foo.XYZ=true -Dcom.acme.name=BAR".
> 
> Having said that, depending on the contents of `argfile`, those could be equivalent. In fact, they are with `--unlock-run-image`, and an empty `argfile`. `--unlock-run-image` avoids adding the marker file, which is the only difference when we extract the image.
> 
> `--save-jlink-argfiles` brings a strange angle to this discussion, but it's conceivable to get a similarly different image, even with --keep-packaged-modules. 

Right.  This example intends to show that the behavior is not straight-forward for users to follow and also subject to the implementation of each of the plugins.   I think we need an easy-to-understand model for developers to understand.   Some possible options:

Option 1: all plugins applied in `image1` are _auto-applied_ to `image2` by default
Option 2: all plugins applied in `image1` are _not applied_ to `image2` by default 

When there is an exception, it should be documented clearly by the plugin (possibly in the output from `--list-plugins`).   I also think option 1 may be more useful to the developers.   I'm not sure how many plugins can undo the transformation done in `image1` when creating `image2`.

For example, with option 1,

$ jdk22/bin/jlink --add-modules jdk.compiler,jdk.jlink --output image1 --vendor-bug.url https://xyz.com/bugs --save-jlink-argfiles argfile --generate-jli-classes jli_trace.txt --strip-debug --add-options "-Dcom.foo.XYZ=true"

$ image1/bin/jlink --add-modules jdk.jlink --output image2 --add-options "-Dcom.acme.name=BAR"
# equivalent to:
$ jdk22/bin/jlink --add-modules jdk.jlink --output image2 --vendor-bug.url https://xyz.com/bugs --save-jlink-argfiles argfile --generate-jli-classes jli_trace.txt --strip-debug --add-options "-Dcom.foo.XYZ=true  -Dcom.acme.name=BAR"

$ image1/bin/jlink --add-modules java.base --output image3 --vendor-bug.url https://com.acme/bugs
# equivalent to:
$ jdk22/bin/jlink --add-modules java.base --output image3  --generate-jli-classes jli_trace.txt --strip-debug --add-options "-Dcom.foo.XYZ=true" --vendor-bug.url https://com.acme/bugs


Discussion points are:
- `--save-jlink-argfiles` is only applicable when `jdk.jlink` is added to the custom module.  I think this one is not an issue.
- `--add-options` concatenates the options? 
- `-vendor-bug.url https://xyz.com/bugs --vendor-bug.url https://com.acme/bugs` last one wins?

We need to go through each plugin and decide on its behavior.   I'm also pondering how the Plugin API should support this run-time image based linking.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1813370985


More information about the core-libs-dev mailing list