8197532: Re-examine policy for the default set of modules when compiling or running code on the class path
david.lloyd at redhat.com
Tue Jun 19 13:46:57 UTC 2018
FWIW I strongly support this change.
On Tue, Jun 19, 2018 at 3:32 AM Alan Bateman <Alan.Bateman at 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:
> 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).
More information about the jigsaw-dev