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

[Severin Gehwolf]

On Thu, 18 Jan 2024 21:35:06 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > > If I read the code correctly, the image created with this option will enable multi-hops unconditionally? i.e. no timestamp file created and disable the check completely. I think the .stamp file should be present in any image created without packaged modules.

OK, done in the recent version.

> What I tried to point out is the following:
> 
>     1. run `myruntime/bin/jlink` to create `image1` without packaged module
>     2. run `image1/bin/jlink` to create a runtime image will fail
>     3. run `image1/bin/jlink --ignore-modified-runtime` will successfully to create `image2`
> 
> I expect `image2/bin/jlink` should fail creating a runtime image since it's multi-hop. Another scenario: If I modify `image2/conf/net.properties` , `image2/bin/jlink` should fail. In both cases, `image2/bin/jlink --ignore-modified-runtime` will ignore the error and create the runtime image.

This should now be fixed. The stamp file indicating a runtime image created image is now always added.


$ rm -rf ./build/jdk.jlink-runtime && ./build/linux-x86_64-server-release/images/jdk/bin/jlink --output ./build/jdk.jlink-runtime --add-modules jdk.jlink
$ rm -rf ./build/image1/ && ./build/jdk.jlink-runtime/bin/jlink --add-modules jdk.jlink --output  ./build/image1/ --verbose
Linking based on the current run-time image.
'./build/image1' is linked equivalent to using jlink with JDK packaged modules as:
    jlink --add-modules jdk.jlink --output ./build/image1

java.base jrt:/java.base (run-time image)
java.compiler jrt:/java.compiler (run-time image)
jdk.compiler jrt:/jdk.compiler (run-time image)
jdk.internal.opt jrt:/jdk.internal.opt (run-time image)
jdk.jdeps jrt:/jdk.jdeps (run-time image)
jdk.jlink jrt:/jdk.jlink (run-time image)
jdk.zipfs jrt:/jdk.zipfs (run-time image)

Providers:
  jdk.compiler provides com.sun.tools.javac.platform.PlatformProvider used by jdk.compiler
  java.base provides java.nio.file.spi.FileSystemProvider used by java.base
  jdk.zipfs provides java.nio.file.spi.FileSystemProvider used by java.base
  java.base provides java.util.random.RandomGenerator used by java.base
  jdk.compiler provides java.util.spi.ToolProvider used by java.base
  jdk.jdeps provides java.util.spi.ToolProvider used by java.base
  jdk.jlink provides java.util.spi.ToolProvider used by java.base
  jdk.compiler provides javax.tools.JavaCompiler used by java.compiler
  jdk.compiler provides javax.tools.Tool not used by any observable module
  jdk.jlink provides jdk.tools.jlink.plugin.Plugin used by jdk.jlink
$ rm -rf ./build/image2/ && ./build/image1/bin/jlink --add-modules jdk.jlink --output  ./build/image2/
Error: Module path to the JDK packaged modules must be specified. Run-time image based linking is not supported as $java.home was already created from a run-time image.
$ rm -rf ./build/image2/ && ./build/image1/bin/jlink --ignore-modified-runtime --add-modules jdk.jlink --output  ./build/image2/
Error: Module path to the JDK packaged modules must be specified. Run-time image based linking is not supported as $java.home was already created from a run-time image.


> `JRTArchive::collectFiles` is the relevant code:
>
>```
>            // add/persist a special, empty file for jdk.jlink so as to support
>            // the single-hop-only run-time image jlink
>            if (singleHop && JDK_JLINK_MODULE.equals(module)) {
>                files.add(createRuntimeImageSingleHopStamp());
>            }
>```

This is now:


if (JDK_JLINK_MODULE.equals(module)) {
       files.add(createRuntimeImageSingleHopStamp());
}


> My intent is to bring up my observation for discussion. The plugin authors are the ones who should decide if the plugin should restore the data from the runtime image to original form. It needs a way to indicate that the transformed data won't persist for this plugin. So far I think FILTER category may be adequate but it may be better to define a new type. This requires some prototype to determine what is the right way.

In the current patch, there is `boolean Plugin::runTimeImageLinkPersistent()` which is exactly what you describe here. The default implementation returns true for `FILTER` or `TRANSFORMER` categories, but this could be explicit for `--vendor-version` et. al. plugins. Unless I misunderstood. I.e. if the `transform()` method is persistent for runtime image based links then it must return `true`. 

> I also agree with Alan that --verbose output is a bit confusing (my initial feedback). The image
has already been created. The users can't tell which plugins are implicitly
run. To list the plugin options, it has to delete the already-created image
and re-do the jlink command with --verbose.

This has been addressed in the most recent version by this output when performing a run-time image based link:


$ rm -rf ./build/image1/ && ./build/jdk.jlink-runtime/bin/jlink --add-modules jdk.jlink --output  ./build/image1/
Linking based on the current run-time image. Details for reproducing the image using JDK packaged modules are in file runtime-jlink-details.txt or are shown when using --verbose.
$ cat runtime-jlink-details.txt
'./build/image1' is linked equivalent to using jlink with JDK packaged modules as:
    jlink --add-modules jdk.jlink --output ./build/image1


So there is no need to re-create the image with `--verbose`. The file has the details. Please let me know if there are more concerns that need addressing.

More thoughts, @mlchung?

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

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