If we do this, shouldn’t we provide an aggregator module to allow developers to easily create a Java runtime with the same list of modules? AFAIK, this doesn’t exists. The java.se <http://java.se/> module is not the same. It’s missing many modules.
Bob. > On Jun 2, 2018, at 1:01 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 02/06/2018 15:07, Magnus Ihse Bursie wrote: >> 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. >> > Removing old cruft is good. Also not building the jre image by default might > reduce build times a little bit, a boon for those doing "make images" but > never using the jre image (as the tests are run on the jdk image, not the jre > image). > > I don't have an opinion on whether configure option or a make target is the > right approach. It might be that those consuming the jre image today are > using the bundles target, a target that I wouldn't expect most developers > will use when working on OpenJDK. Part of the socializing of this topic might > be to get a better handle on what downstream projects and packagers are doing > with the jre image (beyond creating install bundles for specific distros). > > -Alan
