Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

[mark.reinhold at oracle.com]

2017/4/3 10:34:14 -0700, Stephen Colebourne <scolebourne at joda.org>:
> On [1] the conclusion given the premise is not unreasonable. The file
> name can be easily changed by a developer or build tool to match the
> expected module name. However, it is the premise I strongly object to:
> 
> "The fundamental problem here is that we're trying to infer a .. name..."
> 
> Inferring a name (identifier) is generally a bad idea in any
> programming context, but especially so in this one where it will be
> baked into the compiled artifacts. Accepting that inferring a name is
> a fundamentally bad idea leads to examination of alternatives to
> automatic modules [3].
> 
> Such an examination yields an approach where a module only specifies
> dependencies on proper modules, with some ability to express that its
> dependencies are incomplete. This appears not to have been considered
> despite being equivalent in aiding migration yet avoiding any need to
> infer a name.

The problem with any approach that allows you to give a stable name to
what is otherwise an automatic module is that the API of that module is
inherently unstable.  If and when the module is completely modularized
then its API will almost certainly change, which in turn will require
incompatible changes to any previously-published fully-modularized
modules that depend upon it.

Further thoughts here:

  http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000682.html

- Mark