Hi Alex, > On 7/6/2017 11:37 PM, Langer, Christoph wrote: > >> On 7/4/2017 12:02 AM, Langer, Christoph wrote: > >>> I have some piece of software that we ship as a jar file and > >>> which will hence run on a JDK 9 in the unnamed module. However, > >>> this jar file contains a package that is also contained in our > >>> JDK image in a module that is always part of the runtime. > >> > >> It would be remiss of me if I didn't ask for some details about why > >> this scenario has arisen. From "always part of the runtime", I > >> would have guessed the package is in java.base, but you also > >> mention "our JDK image" so perhaps the package is in a module that > >> SAP always jlinks in? > > > > Thanks for your interest in the details. Here it is: We have a > > separate module that exposes an augmenting SAP specific API which is > > publicly exported. This module is part of our JDK image. > > The default set of root modules for the unnamed module is specified by > JEP 261 rather than a JSR, but I guess the SAP JDK implementation uses > the same default set as the OpenJDK implementation. Then, since your > separate module exports a package without qualification, the separate > module is in the default set.
Exactly, this is how it is designed. > You could mark the separate module as DoNotResolveByDefault so that it > is observable *but not readable* by the unnamed module which holds your > JAR file's tool classes + copies of SAP-specific API/impl classes. > > Or, given that the JAR file is meant to be cross-JDK and so should never > be aware of the separate module, your tool's launch script could make > the separate module unobservable (--limit-modules). OK, this maybe is a good idea to try. When I'm running my JDK-independent tool on top of our VM, then this public API is not used and probably neither of its dependents. I'll test that. Thanks a lot for your consulting. Best regards Christoph
