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

[Severin Gehwolf]

On Thu, 14 Mar 2024 20:54:32 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > The updated patch uses a **build-only** `jlink` plugin, still called `--create-linkable-runtime` which is _a)_ added only at build time with `--add-modules` and _b)_ now generates the diff and prepares the image for runtime linking as before in one step. The code for this now lives in `src/jdk.jlink/build/classes`.
> 
> This patch introduces a new module `jdk.unsupported_jlink_runtime` . `src/jdk.jlink` should only contain one module (see JEP 201). If it ought to have another module, its source files should be placed under `src/$MODULE`.

Got it, thanks. I guess it would be the first build-only module, would it?

> I would suggest to simplify it - drop the new module `jdk.unsupported_jlink_runtime` and simply include all its classes in `jdk.jlink` module; for example in `jdk.tools.jlink.internal.runtimelink` package to follow the existing jlink package name hierarchy. This package can only be compiled when JDK is configured to build linkable images. The build can simply invoke `jlink --create-linkable-runtime` and avoids all the setup to add exports to this build tool. If jlink is running from a linkable image, --create-linkable-runtime` plugin should be disabled and hidden. What do you think?

I'm a bit confused. Wasn't the intention to make "creating a linkable runtime image" a build only decision and make the relevant infrastructure classes build-only artefacts? Maybe I misunderstood what "internal option" means exactly and what the minimal requirements of "make it internal" are.

Let me paraphrase what I think you mean by the proposed simplification:

## Case 1: `--enable-runtime-link-image == disabled` 

The `jdk.jlink` module doesn't include classes for creating a runtime linkable image, because `jdk.tools.jlink.internal.runtimelink` classes and resources get excluded during compilation. We probably need to do some magic to not list the plug-in in `module-info.java` in that case.

## Case 2: `--enable-runtime-link-image == enabled`

The `jdk.jlink` module does include classes for creating a runtime linkable image because the JDK build needs those at JDK build time and invokes `--create-linkable-runtime` in order to produce the jimage which is later suitable for linking from the runtime image. It needs to distinguish between `jlink` invoked at JDK build time and other cases (such as jlink running from packaged modules, or jlink based on the runtime image later at runtime). Once the JDK is shipped, it needs to disable the plugin (since the classes are going to be part of the jimage).

In summary, we'd have a somewhat less clunky way to actually produce a linkable runtime at JDK build time. However,  the added complexity and divergence for cases 1 and 2 using that approach seem less than ideal too. Perhaps I'm missing something, though. Thoughts?

To me, going the build-only module approach seemed the cleanest as we only need some magic to enable the plugin at JDK build-time, but don't need to worry about divergence of jdk.jlink module otherwise. The difference of the `jdk.jlink` modules is the absolute minimum: Tracking files for natives/configs and anti-delta diffs to the packaged modules. Since the classes/plugins are separate from `jdk.jlink` and the extra module isn't part of the JDK modules to be shipped, we cover the case of users not having any way to create a linkable runtime with only the compiled JDK. Using the build-only module approach doesn't care whether or not it's a `--enable-runtime-link-image` produced JDK at runtime.

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

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