On 11/18/2019 4:34 AM, Alan Bateman wrote:
The summary on this issue is that service binding augments the
module graph with the modules induced by the service-use relation.
... If service binding were to resolve `jdk.incubator.jpackage` > then a
warning would be emitted in all phases that java.base
is resolved (so everywhere).
... The change proposed here means that incubator modules are not
candidates to add to the module graph during service binding for the
boot layer's configuration. It has no impact on the general case
where incubating modules may be observable when creating the
configuration for custom layers.
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.*****
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.)*****
During the JDK build, incubator modules must be packaged ...
-----
Alex
