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

[Severin Gehwolf]

On Fri, 8 Dec 2023 15:44:07 GMT, Alan Bateman <alanb at 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