On 3/10/2016 6:33 PM, Stephen Felts wrote:
I'm aware of classes in our application server (not javax) that are
unused when running with our own JVM and used when running with
another JVM. In that case, the packages are duplicate of classes in
the JDK. I would not want that usage to generate a fatal error. This
is unrelated to endorsed jar files.
I agree that such usage should not generate a fatal error when we're
talking about duplicates of non-java.* and non-javax.* classes.
Let's say your classpath JAR has foo.bar.* classes that happen to
overlap with a named module's internal classes (i.e. doesn't export
foo.bar). This isn't a bug in your JAR -- in general you don't and
shouldn't know the internals of any named module, whether JDK or user,
whether in the image or on the modulepath.
What happens at run time? :-
- If the named module is mapped to the bootstrap or extension loader
because it's a well known JDK module, then no problem -- the application
loader has no reason to delegate for foo.bar.* classes (the JDK module
didn't export it) nor will the application loader search any of its own
named modules for the package (since none of them export it either). The
application loader will look in its unnamed module by searching the
classpath, and find your JAR's foo.bar.* classes.
- If the named module is mapped to the application loader, then the
application loader will search in that module when code in that module
accesses foo.bar.* classes. The classpath JAR is ignored. Even after the
application loader has defined foo.bar.* classes from the named module,
they're inaccessible to code in the unnamed module, despite being in the
same loader. [Strong encapsulation.]
The takeaway from all this algebra is that either your classpath JAR's
package is used completely (because no named module dominated it) or
it's not used at all (because a named module dominated it). [Reliable
dependencies -- even a legacy JAR that doesn't declare dependencies is
still guaranteed a package that, because it's not split, will work
reliably.]
Alex
