A better solution to the first and third issues is the main hope people I meet on a daily basis have for the JPMS effort, far ahead of encapsulation/having a better way of indicating what the 'real' API of a module is (which is of course solved by JPMS). It would be sad to see those hopes dashed, especially since it looks like solutions are within reach. Regards, Petter On Mon, 6 Mar 2017 at 18:27 <mark.reinhold@oracle.com> wrote:

Issue summaries ---------------

#AvoidConcealedPackageConflicts -- Provide a simple means to load two modules, without using reflection, when they contain non-exported packages of the same name. This could be done by loading them via different class loaders or, alternatively, via #StaticLayerConfiguration. [1]

#StaticLayerConfiguration -- Layers can, at present, only be created dynamically, via reflection. If there were a way to specify them statically, i.e., at startup time, then they could be used to solve the kinds of version conflicts that are presently addressed via shading or shadowing. [2]

#MultipleModuleVersions -- Allow multiple distinct modules of a given name to be loaded in a convenient fashion, without using reflection. This could be done by creating new layers automatically, or by relaxing the constraints on multiple versions within a layer, or by some other means (cf. #StaticLayerConfiguration, #AvoidConcealedPackageConflicts). Addressing this issue may entail reconsidering the multiple versions non-requirement. [3]

Proposal --------

These overlapping issues do reflect actual, practical problems. There are, however, already effective -- if somewhat crude -- solutions to these problems via techniques such as shading (in Maven) and shadowing (Gradle). More sophisticated solutions could be designed and implemented in a future release.

The lack of immediate solutions to these problems should not block a developer who wants to modularize an existing class-path application. If such an application works properly on the class path today then it likely does not have conflicting packages anyway, since conflicting packages on the class path almost always lead to trouble.

[1] http://openjdk.java.net/projects/jigsaw/spec/issues/#AvoidConcealedPackageCo... [2] http://openjdk.java.net/projects/jigsaw/spec/issues/#StaticLayerConfiguratio... [3] http://openjdk.java.net/projects/jigsaw/spec/issues/#MultipleModuleVersions