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