Proposal: #AutomaticModuleNames

Mon Apr 3 16:30:15 UTC 2017

Issue summary
-------------
 #AutomaticModuleNames -- Revise the algorithm that computes the names
 of automatic modules to include the Maven group identifier, when
 available in a JAR file's `pom.properties` file, so that module names
 are less likely to collide, or else drop the automatic-modules feature
 entirely, since it may be more trouble than it's worth. [1]
Proposal
--------
 - Do not revise the algorithm that computes the names of automatic
 modules. The suggestion to use Maven coordinates when available [2]
 would help less than half of the most popular projects in use today,
 as determined by three different surveys. It would result in module
 names that are either annoyingly verbose or not so obviously related
 to their artifacts' original coordinates, and in either case known to
 be objectionable to some module authors. It would, finally, raise
 non-trivial issues with regard to standardization and convention.
 No algorithm better than the current one has been proposed. [3]
 - Do not drop the automatic-modules feature. It's a critical part of
 the overall JPMS migration story, and it's been well-received by a
 wide variety of developers despite the fact that some expert users
 are not comfortable with it.
 - To increase awareness of when automatic modules are used, and of the
 consequences of their use, encourage Java language compilers to issue
 two new types of warnings, and implement these warnings in the RI:
 - An opt-in (i.e., off-by-default) warning on a reference to
 an automatic module in a `requires` directive in a module
 declaration, and
 - An opt-out (i.e., on-by-default) warning on a reference to
 an automatic module in a `requires transitive` directive in
 a module declaration.
 The first warning allows developers to be maximally hygienic if they
 so choose. The second helps make the author of an explicit module
 aware that they're putting the users of that module at risk by
 establishing implied readability to an automatic module.
 - Encourage Java run-time systems to make it easy to identify via,
 e.g., command-line options, which observable modules are automatic,
 which observable modules would establish implied readability to
 automatic modules if resolved, and which automatic observable modules
 are actually resolved. Implement these capabilities in the RI.
 - Strongly advise developers never to publish, for broad use, explicit
 modules that require automatic modules. That's risky: An automatic
 module is unreliable, since it can depend on types on the class path,
 and its name and exported packages could change if and when it's
 converted into an explicit module. It's fine to declare and use
 explicit modules that require automatic modules in limited settings,
 but they should never be published to Maven Central or any similar
 public repository.
 - Do not implement the previous suggestion to define a `Module-Name`
 manifest attribute [4][5]. It would be confusing, because it would
 establish two ways to name a module, one of which is rooted in the
 past. It would also make it easy for people other than the author
 of a module, e.g., tool maintainers [6], to try to establish the
 module's name via the default effect, a move to which many module
 authors would understandably object.
 Not defining this attribute does mean that authors and maintainers
 who want to modularize existing components yet continue to support
 those components on earlier releases will have to do a bit more work
 in order to create `module-info.class` files. It's straightforward
 to create standalone tools to address this need for those who are
 unable or unwilling to build on JDK 9.
[1] http://openjdk.java.net/projects/jigsaw/spec/issues/#AutomaticModuleNames
[2] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-January/000537.html
[3] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000666.html
[4] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-February/000582.html
[5] http://openjdk.java.net/projects/jigsaw/spec/issues/#ModuleNameInManifest
[6] http://mail-archives.apache.org/mod_mbox/maven-dev/201702.mbox/%3CCAMk_Beg2ir9e65hXG9RSNVFdWNYMr02aTh%3Dd%3DfCWL%2BWof-aXpw%40mail.gmail.com%3E