8197532: Re-examine policy for the default set of modules when compiling or running code on the class path

[Alan Bateman]

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