On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung <mch...@openjdk.org> wrote:
>> Severin Gehwolf has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Move CreateLinkableRuntimePlugin to build folder >> >> Keep runtime link supporting classes in package >> jdk.tools.jlink.internal.runtimelink > > Thanks for the investigation w.r.t. extending jimage. It does not seem worth > the effort in pursuing the support of adding resources to an existing jimage > file. To me, putting the diff data under `lib` directory as a private file > is a simpler and acceptable solution. It allows the second jlink invocation > to avoid the plugin pipeline if the per-module metadata is generated in > normal jlink invocation. > > (An observation: The current implementation requires the diffs to be > generated as a plugin. For this approach, it may be possible to implement > with a separate main class that calls JLink API and generates the diffs.) > > @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? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2058919838
