Proposal: #AvoidConcealedPackageConflicts, #StaticLayerConfiguration, & #MultipleModuleVersions

mark.reinhold at mark.reinhold at
Mon Mar 6 17:16:25 UTC 2017

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]


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.


More information about the jpms-spec-experts mailing list