On Fri, 8 Mar 2024 16:47:33 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
> What is the rationale for introducing a special configure flag for this > functionality? I've tried to look though all comments in this PR, and read > the JBS issue and CSR, but I have not found any motivation for this. I'm > sorry if it's there and I missed it, but this is a huge PR with a lot of > discussion. > > In general, it is better not to introduce variants of the build like this. > The testing matrix just explodes a bit more. And my understanding from the > discussion is that this functionality is likely to be turned on anyway, > otherwise you'll build a crippled jlink without full functionality. The JDK image (images/jdk) includes the packaged modules (as .jmod files) that the jlink tool can use to create other run-time images. The proposal here isn't meant to change this. "make images" should create the JDK image as before and that image will include the packaged modules. The inclusion of the packaged modules has been problematic in some environments, esp. when there are debug symbols. libjvm.so can be huge, which begs the question as to why there is a copy in java.base.jmod. There are of course options to build the JDK image without --keep-packaged-modules and host the packaged modules as a separate download. Back in the JDK 9 we decided not to do this for Oracle downloads. Severin has implemented an approach that allows "observable modules" be found in the current run-time image when using jlink. This requires some heretics and computation of diffs between the bits in the original packaged modules and the transformed bits in the run-time image. This exploration has gone through many iterations. Recently, Severin, Mandy and I have met to try to simplify things and tame the goals in order to get to something that is maintainable, and to allow time to get experience with this direction. So at a high-level, the intention is that the build be capable of producing an alternative JDK image that doesn't have a "jmods" directory. The jlink tool in that image has a limitation, a compromise to keep the complexity at a manageable level. I have no opinion on whether the opt-in is at configure time or its just make target (like "make legacy-jre-image"). In the discussions it wasn't meant to be built by default. If distributions choose to distribute this image then this will likely influence what they test. Once experience builds up with using these run-time images then it may be that there is a proposal (and JEP) to make it the default, meaning images/jdk would not include .jmod files and multi-hop restriction is removed from jlink. That may be something for much further down the road. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1986796401
