New issue: #ModuleIdentifiers

mark.reinhold at mark.reinhold at
Wed May 17 18:32:56 UTC 2017

Over the last few weeks it's become clear that some members of the Java
community are disappointed that JPMS does not solve the "multiple-version
problem".  This was, of course, a deliberate decision, as captured in the
agreed multiple-versions non-requirement [1].  In my proposal to close
the related #MultipleModuleVersions issue [2] I wrote [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.

If we do address this problem in a future release then it's highly likely
that modules will need to be identified not just by names but also by
version strings or some other information that discriminates between
different modules of the same name.  To leave a path to that potential
future I suggest that the JPMS Specification address the following new
issue [4]:

  #ModuleIdentifiers -- To leave open the possibility in a future release
  of identifying modules not just by their names but also by some sort of
  versioning information, refactor the `java.lang.module` API to
  introduce a `ModuleId` class and to use instances of that class rather
  than bare `String` objects wherever modules are named.  This class
  will, for now, simply wrap a string.  In a future release it can be
  enhanced, if needed, also to carry versioning information.

- Mark


More information about the jpms-spec-experts mailing list