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. 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