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

[Alan Bateman]

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

I think you've got this to a good place and I think the overall solution is good. It may be that JDK should move to this by default in the future, and at the same time re-visit the restriction on generating an image containing jdk.jlink, but let's see if any issues come up.

I've added myself as Reviewer to the CSR and I'm working through the code changes.

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

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