Proposal: #AvoidConcealedPackageConflicts, #StaticLayerConfiguration, & #MultipleModuleVersions

[Petter Måhlén]

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 at 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/#AvoidConcealedPackageConflicts
> [2]
> http://openjdk.java.net/projects/jigsaw/spec/issues/#StaticLayerConfiguration
> [3]
> http://openjdk.java.net/projects/jigsaw/spec/issues/#MultipleModuleVersions
>