Proposal: #AutomaticModuleNames

[mark.reinhold at oracle.com]

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