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

[Alex Buckley]

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.

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).

Alex