[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-jigsaw-dev
Subject:    Re: 8197532: Re-examine policy for the default set of modules when compiling or running code on the 
From:       mandy chung <mandy.chung () oracle ! com>
Date:       2018-06-21 14:46:10
Message-ID: 95fd4842-2ef6-49b8-832b-1a66438b6b95 () oracle ! com
[Download RAW message or body]

I looked through the change and looks good.

Mandy

On 6/19/18 1:31 AM, Alan Bateman 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
[prev in list] [next in list] [prev in thread] [next in thread]