2018-06-19 08:31:47 UTC
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:
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).