This issue concerns the interaction of service binding with incubator modules, a left over from JDK 9 that resurfaces with the upcoming JEP 343 Packaging Tool (Incubator).
The summary on this issue is that service binding augments the module graph with the modules induced by the service-use relation. This happens irrespective of the incubating status of the observable modules because the incubating designation is a JDK rather than Java SE/specified concept. It shows up with module `jdk.incubator.jpackage` because this module wants to implement the `java.util.spi.ToolProvider` service interface, a service interface used by `java.base`. 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).
It's on my radar to more precisely specify service binding and also work out the specification changes needed to allow filtering of the observing modules but this is not needed at this time. Instead, we can limit the changes to the configuration for the boot layer as the set of observable modules when creating the configuration for the boot layer is not specified (it's up to the implementation). 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.
While in the area, I've also fixed the existing DefaultModules test to allow for incubator modules as this test has been failing the jpackage branch. We didn't have any incubator modules in JDK 11, when the test was added, to notice this oversight in the test.
The webrev with the proposed changes is here. The reason that the jlink system modules plugin is updated is because it creates the configuration for the boot layer at link-time, for cases where we are skip resolution at run-time.
http://cr.openjdk.java.net/~alanb/8233922/webrev/ -Alan.
