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
