FWIW I strongly support this change. On Tue, Jun 19, 2018 at 3:32 AM Alan Bateman <alan.bate...@oracle.com> wrote: > > > JEP 261 details how the default set of root modules is computed when > compiling code in the unnamed module or when running code and the main > class is loaded from the class path. I'd like to re-visit this policy > for JDK 11 with two motivations: > > 1. If jlink is used to create a run-time image that contains java.se and > other API-exporting java.* modules that aren't in Java SE then these > other modules will not be resolved by default when using this run-time > image to compile or run code on the class path. > > 2. The policy in JEP 261 was crafted to ensure that the java.corba and > Java EE modules are not resolved by default. These modules are proposed > to be removed in Java SE 11 (and were removed for the first build of JDK > 11) so the need to exclude these modules goes away. > > The proposal is to change the policy so that the default set of root > modules for the unnamed module is simply "the observable modules on the > upgrade module path or among the system modules that exports at least > one package, without qualification". > > As the policy is JDK-specific it means there aren't any specification > changes. The only docs change is to non-normative text in > java.lang.module's package description. > > Changing the policy requires small changes to both compile-time and > run-time. In addition we have the jlink "system modules" plugin that > implements this policy to generate the code used at run-time to > reconstitute the module descriptors for the default modules. > > Testing: For the most part, running the existing tests is sufficient as > the tests exercise all APIs and are mostly in the unnamed module. To > test the java.se plus other java.* modules, a new test is added that > creates a run-time image with "java.se" and a module named "java.json" > that exports an API. The resulting run-time image is used to compile and > code in the unnamed module (the JEP 330 support for single-file programs > makes this easy). > > The webrev with the proposed changes is here: > http://cr.openjdk.java.net/~alanb/8197532/webrev/ > > The CSR for the change is linked from the bug. The only behavioral > impact is that the "java.se" aggregator module is not resolved resolved > (at least not unless there is an API-exporting or service provider > module in the run-time image that requires java.se). > > -Alan
-- - DML
