Revised proposal for #AutomaticModuleNames

[Stephen Colebourne]

On 5 May 2017 at 15:41,  <mark.reinhold at oracle.com> wrote:
> 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.

I think this is the tricky part. Lets review where we are.

Firstly, we now have super-package reverse-DNS names and MANIFEST
entries. Both of these are a very good thing.

Secondly, a module with a module-info can now depend on three things:
- an explicit module with a module-info  (good)
- an automatic module with MANIFEST entry  (good)
- an automatic module with name implied from filename  (not good)

Thirdly, given the nature of Maven Central, it is not realistic to
prevent modules with dependencies on names implied from filenames
getting into Central.

My remaining concerns with automatic modules are primarily about this
last point - we have to accept that there will be modules with "bad
dependencies" in Maven Central. For example, the graph will end up
with a dependency on "guava" that breaks when Guava is properly
modularized and uses "com.google.common" as the module name. The
result is a graph that does not resolve. While I and others will try
and communicate this issue to the community, I would prefer that the
issue simply could not occur.


However, it has been pointed out to me off-list that there is a way to
workaround the name change that I had not fully appreciated before.

Given this broken module graph state:

 module com.foo.application {
   requires guava;
 }
 module com.google.common {
 }

it is possible to fix it by introducing an additional module as follows:

 module guava {
   requires transient com.google.common;
 }

With this additional "renaming shim module" in the graph, everything
now works again.

Given that there is a potential workaround, I am not as concerned as I
previously was about this issue.


Ideally, the creation of this "renaming shim module" should be part of
the JDK (effectively it is a kind of alias, and the JDK is best placed
to manage this). However, it should also be possible for tools like
Maven to provide the shim dynamically when needed. It would even be
possible to release such a shim module to Maven Central and depend on
it in the usual way.

While this is still a workaround to an issue I wish didn't exist in
the first place, it is a viable solution that I think allows automatic
modules to proceed as is (given the JSR/release timeline pressure).

Stephen