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

[Severin Gehwolf]

On Thu, 16 Nov 2023 19:00:57 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Thanks.
>> 
>>> How can the user know what plugins are applied to `image2`? i.e. what is the jlink command to produce `image2` if running from `jdk22` with the packaged modules present?
>> 
>> The only way to know is by knowing the chain of `jlink` commands yielding up to the final image. Let `jlink'` be the jlink using packaged modules. Currently this can be at most two. In addition, the contents of `argfile` needs to be known. That doesn't seem to be very different to the status quo, though. See below.
>>  
>>> Reading the changes, I'm not sure but I think it's not 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" --add-options "-Dcom.acme.name=BAR"
>>> ```
>> 
>> 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. Consider:
>> 
>> 
>> echo '--add-options=-XX:+UseParallelGC' > argfile
>> ./jdk22/bin/jlink --save-jlink-argfiles argfile --strip-debug --add-modules jdk.jlink --keep-packaged-modules ./image_a/jmods --output image_a
>> ./image_a/bin/jlink --add-modules java.base --output image_b
>> 
>> 
>> It's not very apparent that `image_b` will have `-XX:+UseParallelGC`. So you need some sort of track record what you've used previously already in order to know how `image_b` got produced (short of `--save-opts`)?
>> 
>>> I think this behavior should be documented.
>> 
>> Makes a lot of sense. Where? In the CSR?
>> 
>>> > 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...
>
>> > We need to go through each plugin and decide on its behavior.
>> 
>> OK. I'll add documentation to the `--list-plugins` help should there be deviations.
> 
> It'd be helpful if you write down your proposed behavior for each plugin for discussion.   Otherwise, we will have to find out from the code.
> 
>> > I'm also pondering how the Plugin API should support this run-time image based linking.
>> 
>> It could, but doesn't need to IMO. OTOH, `transform()` could grow an argument to indicate packaged-modules vs runtime image link.
> 
> I'm not sure if it needs the extra argument.   As the plugin knows what files it adds, it can always check its existence as the current implementation is doing.   What I'm thinking if the plugin will need to indicate if it'd concatenate, retain or drop the transformation from `image1` when creating `image2.   This will get the plugin author to consider that when the plugin is developed.
> 
> Regarding the name of the `runimage_resources` file, this file is only used by jlink and so it can be a resource file in `jdk.jlink` module like `jdk.jlink/jdk/tools/jlink/internal/runtime/$MODULE_resources` (e.g. `jdk.jlink/jdk/tools/jlink/internal/runtime/java.base_resources`)

@mlchung Just as an FYI, I'm working on it. Thanks!

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

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