Revised proposal for #AutomaticModuleNames

[mark.reinhold at oracle.com]

2017/5/5 3:04:15 -0700, Robert Scholte <rfscholte at apache.org>:
> thanks for these adjustments. In general they look good, but it all  
> depends on the details:
> 
>      Define a JAR-file manifest attribute, `Automatic-Module-Name`, whose
>      value is used as the name of the automatic module defined by that JAR
>      file when it is placed on the module path, as previously suggested
>      [2][3].  If a JAR file on the module path does not have such a
>      manifest attribute then its automatic-module name is computed using
>      the existing filename-based algorithm.
> 
> Just to be clear: does this make it an auto module?

Yes, except that its name is taken as the value of the attribute rather
than computed from the JAR file's name.

>                                                     In that case we're  
> still a bit stuck, because I still insist that jars published to any  
> public artifact repository should never refer to an automodule. Published  
> jars with this attribute should have received this name by their developer  
> and this also implies that the jar is Jigsaw-ready, e.g. no more split  
> packages.

If a JAR file works on the module path as an automatic module then it
already can't have any split packages.  It doesn't matter whether its
name is given in the attribute or computed from the filename.

>           In the future its users should be able to switch to the fully
> modular jar with the same name without any problem. So I need an extra
> state, e.g. isAutomatic() + isNamed(), in which case I have to change my
> insisting line: "Never publish jars to any public artifact repository that
> refers to *unnamed* automatic modules".

All automatic modules are named, either from the above attribute or
from the filename.  That is, `isAutomatic() && isNamed()` will be `true`
for every automatic module.  (Note that `isAutomatic()` is a method on
`ModuleDescriptor` objects, while `isNamed()` is a method on run-time
`Module` objects.  The only "unnamed" modules are those that are
associated with each class loader, for compatibility purposes.)

I suspect what you really mean is "Never publish JARs that refer to
automatic modules that do not have `Automatic-Module-Name` attributes".
In general that's good advice.  It might even be reasonable for managers
of artifact repositories to insist upon it, although I now understand
that that could be problematic for a repository as popular as Maven
Central.

>      A user of a library can suggest a stable name to the library's
>      maintainer, and easily submit a patch that implements it.  This will
>      enable the uncoordinated modularization of libraries across the
>      entire ecosystem.
> 
> I don't think this is realistic. Jars live in the local repository and  
> will stay there even during compilation. Is a user patches such jars,  
> it'll effect all his local Java projects.

As Rémi points out nearby, by "submit a patch" I meant "submit a pull
request" or "send a source-code patch to the maintainer".  If the
maintainer likes the patch then they can merge it and it will show up
in the next release.  If they don't like it then at least they'll know
that some of their users care, and perhaps be motivated to choose the
(reverse DNS!) module name that they prefer and merge that.

- Mark