8233922: Service binding augments module graph with observable incubator modules

Alan Bateman Alan.Bateman at oracle.com
Mon Nov 18 19:10:27 UTC 2019


On 18/11/2019 17:54, Alex Buckley wrote:
> An incubator module's service providers will now be unavailable by 
> default even if a module on the module path says `uses`. I believe 
> that JEP 11 should say the following:
>
> -----
> Incubator modules are part of the JDK run-time image produced by the 
> standard JDK build. *****However, by default, incubator modules are 
> not resolved for applications on the class path. Furthermore, by 
> default, incubator modules do not participate in service binding for 
> applications on the class path or the module path.*****
That looks good.

>
> Applications on the class path must use the --add-modules command-line 
> option to request that an incubator module be resolved. Applications 
> developed as modules can specify `requires` or `requires transitive` 
> dependences upon an incubator module directly. *****(Some incubator 
> modules do not export packages but rather provide implementations of 
> services. It is usually not recommended to require a module that 
> exports no packages, but it is necessary in this case in order to 
> resolve the incubator module and thus have it participate in service 
> binding.)*****
We could potentially say something about tools that are incubator 
modules here. The launcher for the tool, "jpackage" in the case of JEP 
343, will use the name of the incubator module as the root module to 
resolve.

>
> During the JDK build, incubator modules must be packaged ...
There's a typo in this paragraph in that the jmod (and jar) tools use 
"--warn-if-resolved=incubating" rather than 
"--warn-if-resolved=incubator" to package an incubator module.

-Alan


More information about the jigsaw-dev mailing list