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

[Severin Gehwolf]

On Tue, 14 Nov 2023 02:44:39 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I did one pass through the changes.

Thanks for the review!

> Looks like the plugin author has to consider how it should work to support linking without packaged modules.

Yes, to some extent.

> The current implementation `--system-modules` re-applies for every jlink invocation since the transformation depends on the set of modules to be linked in the resulting image.

Yes. The same is true for a run-time image based link for the system modules plugin.

> OTOH `--vendor-bug-url`, `--vendor-version` and `--vendor-vm-bug-url` plugins are auto-applied to the new image created via this run-time image based linking when these options are not specified.

Since some of those things are also possible to specify at build-time (with ` --with-vendor-name` and friends), this applies to the packaged-modules link as well.

> I was wondering what plugins that were applied in the first image are carried automatically during the run-time image based linking? I would assume this will generate an image equivalent to running jlink with the packaged modules present.

I'm not sure I fully understand the question.

Since the run-time image link is fundamentally based on using the modules image (`lib/modules`) plus files on the filesystem of the JDK install (minus `jmods` folder), everything that modifies class files, adds resources, modifies files like stripping debug info from binaries, carries over.

Say, you'd have a link using packaged modules:


jlink --add-modules jdk.jlink --strip-debug --output jdk.jlink-stripped


A link using the run-time image, then would produce a stripped java.base module with this step:


./jdk.jlink-stripped/bin/jlink --add-modules java.base --output java.base-stripped


IMO that's a nice use-case to have. If you want a re-setted link, use the packaged modules instead and start afresh.

> Therefore nothing should be carried automatically from the current run-time image, shouldn't it?

Could you clarify what "carried automatically" means?

> I agree that `--add-run-image-resources` should be hidden and it's not target for developers to use. I consider it's jlink internal implementation. It's auto-enabled and always generates the per-module `runimage_resources`. I think we might need to add `Plugin::showPlugin` or `hidePlugin` to specify if this plugin should be hidden from `--list-plugins`.

OK. Done in the latest version. I've added `Plugin::isHidden`, defaulting to `false`.

> It's good to move `runimage_resources` to some package under `jdk/internal` but each module will need to be a different package name. BTW I found `runimage` a confusing term.

Unfortunately, adding packages like that isn't allowed, since `jlink` performs validation of the known packages using the module descriptor. By adding the resource to a new package, we'd somehow have to modify the module descriptor as well for every module. For now, I've resorted to renaming the resource file to - a still package-less - `jdk_internal_runimage`.

> I am also not certain if we should support `--unlock-run-time` option. Are you trying to make the users do less work to configure some properties files once in the first image and all the custom runtime images created from that will not need to do the configuration?

Yes, that could be a use-case. Personally, I liked the possibility of doing recursive links. There was some beauty to it, since it allows multiple teams to do links suitable to their use-case. But this is now gone with the latest version which uses a marker file to prevent multiple recursive links based on the run-time image.

On the other hand, there are tests part of this patch which verify that a default link for `java.se`  with default options using packaged modules and using the run-time image based link are binary identical. Since any extra resource (like the marker file), destroy this property, I'd like to keep some way to still verify this.

Perhaps doing this less visibly than an actual new CLI option is more amenable? A property akin to `jlink.debug` perhaps? Something like `-Djlink.no-marker`? It could be an undocumented thing.

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

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