Use classes in unnamed module that are also contained in a JDK platform/runtime module

[Langer, Christoph]

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