On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman <al...@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
