Revised proposal for #AutomaticModuleNames

[Robert Scholte]

Hi Mark,

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? 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. 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".

     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. Only when Maven will do both  
compiling and generation the distributable/deployable one could isolate  
jars. However, the concept is that plugins don't have any knowledge of  
each other and shouldn't share any information. In other words:  
maven-war-plugin is not aware of maven-compiler-plugin; the  
maven-war-plugin just collects all the content for the web archive,  
including the jars as specified in the pom.xml, pulling them from the  
local repository.
In case the user is developing an application he might use this, but since  
he can already use automodules, I expect him to use that, it's less  
painful compared to patching its dependencies artifacts.
In case the user is developing a library he cannot use this, nor can he  
refer to automodule, because he doesn't control the combinations of jars  
used by the application developer.

thanks,
Robert

On Thu, 04 May 2017 19:39:06 +0200, <mark.reinhold at oracle.com> wrote:

> Thanks to everyone, and especially Stephen Colebourne, Brian Fox, and
> Robert Scholte, for the extensive feedback.
>
>   http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-May/000687.html
>
> TL;DR: Keep automatic modules, bring back the module-name JAR-file
> manifest attribute, and strongly recommend reverse-DNS module names.
>
> Comments?
>
> - Mark