Explicit file names in module-info - #AutomaticModuleNames

[Stephen Colebourne]

This is a proposal to mitigate some of the worst effects of automatic
modules. Partial modules remain the better solution.

We now have an agreed naming convention (reverse DNS), which is
something we haven't had before. This gives us relatively stable and
predictable names.

But we also know that the module name will differ from the filename in
most cases. As demonstrated before, having two disconnected names will
block migration when forced to move from the filename to the module
name.

Thus, the biggest design problem is that the module depending on an
automatic module is being asked to use the wrong name, with no link to
the right one which they can now predict with reasonable certainty.

As such, my proposal is that the module depending on an automatic
module must specify the long-term stable module name, with the
short-term filename included as additional metadata.

Here is a keyword approach to this:

module org.joda.convert {
  requires com.google.common file guava;
}

Here is an annotation approach that could be used instead:

@Alias(moduleName = "com.google.common" fileName="guava")
module org.joda.convert {
  requires com.google.common;
}

With both of the above, the module declaration uses the correct final
module name from day one, which is vital to not creating future
problems. The long-term stable name can be communicated in many ways,
such as on a website or by email, not just by code or manifest. I can
now release Joda-Convert, whether or not Guava has been modularised.
Success!!!!

The short-term migration-only nature of the filename is much much
clearer. The filename can be removed once the dependency is a module
(and static analysis tools could highlight that). The fileName would
be the Maven artifactId in most cases. (There is a case for the
fileName to be a list of possible filenames for additional
flexibility).

I think this design addresses some of Roberts's concern too. With this
plan, Maven Central would contain modules depending on automatic
modules, but the dependency names would be sufficiently stable for
this not to be the major issue it has been previously.

While I don't think automatic modules are the best option, were the
above chosen, I think it would be a solution the community could
successfully and easily adopt.

Stephen