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

[Magnus Ihse Bursie]

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.

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1986042463