On Thu, 18 Jan 2024 21:35:06 GMT, Mandy Chung <mch...@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
