On Fri, 8 Dec 2023 15:44:07 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 46 commits: >> >> - Add @enablePreview for JImageValidator that uses classfile API >> - Fix SystemModulesPlugin after merge >> - Merge branch 'master' into jdk-8311302-jmodless-link >> - Don't show the verbose hint when already verbose >> - Use '_files' over '_resources' as the suffix for listing resources >> - Remove the hidden option hint. >> >> Also adjust the messages being printed when performing >> a run-time image link. >> - Localize messages, switch expression >> - Rename RunImageArchive => JRTArchive and RunImageLinkException => >> RuntimeImageLinkException >> >> Also moved the stamp file to jdk.jlink module. The resources files per >> module now get unconditionally created (empty if no resources not in the >> jimage). >> - First round of addressing review feedback. >> >> - Share resource names (JlinkTask and JlinkResourcesListPlugin) >> - Exclude resources in JlinkResourcesListPlugin the same way >> as done for other plugins. >> - Rename AddRunImageResourcesPlugin => JlinkResourcesListPlugin >> - ... and 36 more: https://git.openjdk.org/jdk/compare/87516e29...a797ea69 > > I tried out the latest commit (a797ea69). > > The output "The default module path, '$java.home/jmods' not present. Use > --verbose to show the full list of plugin options applied" is bit confusing > as it looks like jlink failed but it actually succeeded. Blowing away the > generated image and retrying with --verbose tripped this assert > > java.lang.AssertionError: handling of scratch options failed > at > jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:675) > at > jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:581) > at > jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:430) > at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:302) > at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56) > at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34) > Caused by: jdk.tools.jlink.internal.TaskHelper$BadArgs: > (...my-original-jdk-directory..)/build/linux-x64/images/jdk/jmods already > exists > at > jdk.jlink/jdk.tools.jlink.internal.TaskHelper.newBadArgs(TaskHelper.java:730) > at > jdk.jlink/jdk.tools.jlink.internal.JlinkTask.lambda$static$12(JlinkTask.java:183) > at > jdk.jlink/jdk.tools.jlink.internal.TaskHelper$Option.process(TaskHelper.java:177) > at > jdk.jlink/jdk.tools.jlink.internal.TaskHelper$OptionsHelper.handleOptions(TaskHelper.java:600) > at > jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:672) > ... 5 more > > I haven't dug into this yet but I'm puzzled that the file path to where the > original build was created is in the exception messages, is that recorded? @AlanBateman @mlchung I've now pushed an update of this patch which now uses a build-time approach as discussed elsewhere. In order to produce a linkable runtime JDK image, one needs to set `--enable-runtime-link-image` at configure time. This then generates a diff from the optimized jdk image to the classes/resources in the packaged modules. The diff is serialized to disk (a `4kb` file, currently) and taken as input to the new jlink plugin `--create-linkable-runtime`, which then adds the conf/libs resources listing and the diff to the `jdk.jlink` module for runtime link consumption. The diff is then applied in `JRTArchive` as appropriate at jlink time. Therefore, jlink plugin authors no longer need to know about which plugins get applied. Runtime link users get a consistent view (as compared to the packaged modules link) when running jlink. A few things that probably still need to be addressed are: - Figure out a way to not duplicate the `ResourceDiff` class. That's mostly done because otherwise one would need to have a `ResourceDiff`-including JDK as boot JDK. A better approach would probably be to do some build magic to copy the class from the build tools area to the `jdk.jlink` generated sources. - Cleanup the tests. I've saved this for a future update as I wanted to get some general feedback first before polishing. - Update the CSR with this new approach (document `--create-linkable-runtime`). Please let me know if this is going in the right direction. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1964809941
