Proposal: #AvoidConcealedPackageConflicts, #StaticLayerConfiguration, & #MultipleModuleVersions
David M. Lloyd
david.lloyd at redhat.com
Mon Mar 6 19:44:23 UTC 2017
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. 
> #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. 
> #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. 
> 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?
More information about the jpms-spec-observers