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

[Severin Gehwolf]

On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > @mlchung @AlanBateman Any thoughts on this latest version? Is this going into the direction you had envisioned? Any more blockers? The CSR should be up-to-date and is open for review as well. If no more blockers I'll go over this patch once more and clean it up to prepare for integration. Thanks!
>>> 
>>> Thanks for all the efforts on this.
>> 
>> Thanks for looking at this, Alan!
>> 
>>> I've looked through the latest version. I'm a little bit comfortable with LinkDeltaProducer. One reason it's build tool that is tied tied to code in the jdk.jlink module, and secondly is that it copies runtime-image-link.delta into the run-time image. Our long standing position is that the run-time image is created by jlink rather than a combination of jlink and extra stuff copied in by the build.
>>> 
>>> The part that I like with the current proposal is lib/runtime-image-link.delta as it's less complicated that previous iterations that added a resource into the jimage container.
>>> 
>>> What would you (and @mlchung) think of having jlink generate lib/runtime-image-link.delta as a step between the pipeline and image generation?
>> 
>> If I understand you correctly, this would be no longer a build-time only approach to produce the "linkable runtime"? It would be some-kind of jlink-option driven approach (as it would run some code that should only run when producing a linkable runtime is requested)? Other than that, it should be fine as the previous iteration basically did that but at a different phase. Also note that the previous iteration used a build-only jlink plugin so as to satisfy the build-time only approach, yet it ran as part of the plugin-pipeline which wasn't desired either. But it was something similar to what you seem to be describing now. Did I get something wrong?
>
>> If I understand you correctly, this would be no longer a build-time only approach to produce the "linkable runtime"? It would be some-kind of jlink-option driven approach (as it would run some code that should only run when producing a linkable runtime is requested)? Other than that, it should be fine as the previous iteration basically did that but at a different phase. Also note that the previous iteration used a build-only jlink plugin so as to satisfy the build-time only approach, yet it ran as part of the plugin-pipeline which wasn't desired either. But it was something similar to what you seem to be describing now. Did I get something wrong?
> 
> I think it continues to build time, it's just using some hidden jlink option. So yes, it similar to a previous iteration except that it doesn't run as a plugin the pipeline and the delta goes to the lib directory.
> 
> Let's see what @mlchung says. You've put a lot of work into this so let's see if we can converge to avoid too many more rounds.

@AlanBateman @mlchung The latest update now uses the `jlink` build time option `--generate-linkable-runtime` to add needed resources to the `jimage` when a runtime linkable JDK image is being asked for using the configure option. This now runs outside the plugin-pipeline. I think this is what you meant. Sorry it took longer to get back to this...

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

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