On Thu, 16 Nov 2023 19:00:57 GMT, Mandy Chung <mch...@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
