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. > > What is the rationale for introducing a special configure flag for this > functionality? I've tried to look though all comments in this PR, and read > the JBS issue and CSR, but I have not found any motivation for this. I'm > sorry if it's there and I missed it, but this is a huge PR with a lot of > discussion. Sorry, yes this was part of a meeting discussion we had outside this PR. My understanding is that by default the produced jimage isn't runtime-link enabled. We (Red Hat) would turn it on in our builds, though. @AlanBateman or @mlchung might have more details. I think it was a requirement to get this patch in. At least for the initial contribution. > In general, it is better not to introduce variants of the build like this. > The testing matrix just explodes a bit more. And my understanding from the > discussion is that this functionality is likely to be turned on anyway, > otherwise you'll build a crippled jlink without full functionality. I would be happy if this could be on by default. For now, I think though we need to work on the premise that whether or not the resulting JDK image is suitable for runtime linking (without jmods) is a build-time config decision. Therefore we need the configure option. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1986098525
