It is probably relatively trivial to add a configure option to select just the "JRE modules" when building, rather than all modules. If we add such an option, it would still be possible to build a traditional JRE, not just at the same time as building the full JDK. Doing Erik's change as suggested here, combined with such additional functionality would allow us to remove a lot of old cruft from the build system, while still allowing distributors to build a JRE. I'd recommend doing something like this, rather than to delay this patch to post-JDK11.
/Magnus > 2 juni 2018 kl. 10:20 skrev Alan Bateman <alan.bate...@oracle.com>: > >> On 02/06/2018 08:05, Aleksey Shipilev wrote: >> : >> Unfortunately, in the age of containers, distribution size matters. It makes >> the whole sense to ship >> JRE in Docker containers to provide the execution environment for the upper >> layers. Remember, hardly >> any application is fully modularized and/or uses jlink/jimage way of >> distribution. >> >> Also, products that ship with their own OpenJDK distribution (e.g. JetBrains >> IDEs) do ship with >> jres, which cuts down their distribution sizes. >> >> Cost savings for having JRE only are significant, as can be observed with >> current bundles: >> >> 178M Jun 2 08:53 jdk-11-internal+0_linux-x64_bin.tar.gz >> 38M Jun 2 08:53 jre-11-internal+0_linux-x64_bin.tar.gz >> >> Therefore, I believe removing jre is too disruptive, at least for 11, at >> least until we see that the >> whole jlink/jimage thing really works out in the wider Java ecosystem and >> JREs are really abandoned. > I don't disagree with the significance of what has been proposed here. > However, just to point out that creating what used to know as the JRE is one > `jlink` command. There is no requirement for the application or libraries > using that run-time be developed as modules. Also incorporate generating of > JDK run-time images into the build when working with containers is very > useful as you get fine control on which modules to include. > > -Alan >
