Proposal: #AvoidConcealedPackageConflicts, #StaticLayerConfiguration, & #MultipleModuleVersions

[David M. Lloyd]

On 03/06/2017 11:16 AM, 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.

We maintain that #AvoidConcealedPackageConflicts and 
#MultipleModuleVersions are essential for developing medium to large 
applications.  Today developers of such applications do not use the 
class path; they use existing systems like OSGi or ours, or they roll 
their own plugin systems.  I don't see how JPMS can be considered to 
fulfill the primary goal stated in its submission if it does not meet 
these simple needs, particularly since they are so easily solved; I 
believe it may be or be nearly a single-line change at this point with 
little if any technical downside that I know of.

The bar is and should be higher than modularizing only existing 
class-path applications.  For most users, the entire value proposition 
of modularity is to easily solve issues like 
#AvoidConcealedPackageConflicts; if they can't solve things like this, 
then why would they move to modules in the first place?  I don't think 
I've ever received a non-surprised response when presenting the issues 
of multiple versions and package conflicts to end users.

As for #StaticLayerConfiguration... that is essentially a proposed 
solution to the other two problems, but I think the more obvious 
solution of multiple class loaders is much simpler both to implement and 
to use, so if this issue were closed in favor of that resolution we 
would be satisfied I think.

Your email didn't specifically say that these issues were closed; does 
that mean that you are still open to discussion on these three issues?

-- 
- DML