Unnamed module and duplicate package

[Alex Buckley]

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