Various resources (infoq, jigsaw-dev, osdir) indicate that having the same package in different java modules will lead to a LayerInstantiationException
, even when t
This definition is open to interpretation. It remains correct as Jigsaw ensures that two modules never define shared packages by crashing the class loading in case of such a conflict.
If you look into Java 9's class loader implementation, you can see that a package name is mapped by to a single module. Its therefore impossible two have two modules to declare ownership. It is however possible that two class loaders in child-parent relationship define the same package.
As said in the discussions you've linked, the issue is about mapping between class loaders and modules.
When you're loading two modules M1
and M2
both containing a non-exported (a.k.a. concealed) package P
via a class loader CL
JPMS has to reject such configuration, since otherwise both key JPMS principles - strong encapsulation and reliable configuration - could be broken. By throwing an exception here JPMS actually implements the requirement you've quoted and ensures that no conflicts may break anything later during the execution.
On the other hand, when you're loading M1
and M2
via two loaders CL1
and CL2
you're actually creating two run-time packages {CL1, P}
and {CL2, P}
, so there is no collision and the Layer
can be instantiated.
The usability problem here is that java
uses single loader for all modules of the application layer (the "starting" one, created from the command-line arguments) which leads to the LayerInstantiationException
. That's currently an open issue on the JPMS list, see [here] (http://openjdk.java.net/projects/jigsaw/spec/issues/#AvoidConcealedPackageConflicts). But regardless of the issue's resolution, if needed, you should be able to deal with the split packages by writing a tiny main class that will create the Configuration
you need (BTW a JPMS-aware application container will probably do it for you).