Revised proposal for #AutomaticModuleNames

[Stephen Colebourne]

On 4 May 2017 at 18:38,  <mark.reinhold at oracle.com> wrote:
>   - 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

This is a step forward wrt automatic modules.

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

Which we all agree is almost guaranteed to be wrong.

>   - To increase awareness of when automatic modules are used, and of the
>     consequences of their use, suggest that Java language compilers issue
>     two new types of warnings, and implement these warnings in the RI:

Perhaps these should be reconsidered? If the module depends on an
automatic module with a module name in the manifest, it can be
considered reasonably stable. Whereas anything depending on a filename
derived module name is unstable. That isn't being captured by the
warnings.

> In related threads on jigsaw-dev both Stephen Colebourne [e] and Robert
> Scholte [f] suggest a new kind of explicit module, variously called
> "partial" or "incomplete" or "soft", which can read all unnamed modules
> so that dependencies that have not yet been modularized can be left on
> the class path.  This is an attractive notion on the surface, and in fact
> one that we partly implemented in the prototype code base over two years
> ago, using the term "loose".  We didn't pursue it then, however, and I
> don't think it's worth pursuing now, for two reasons:
>
>   - If "partial" (or whatever) modules were to replace automatic modules
>     then application developers would have to wait until all of their
>     dependencies have been at least "partially" modularized before they
>     can even begin to experiment with modularizing their own code.

This seems demonstrably false.

module com.foo.application {
  requires com.foo.lib;
}
partial module com.foo.lib {
  exports com.foo.lib;
  // TODO: requires guava
  // TODO: requires joda-beans
}
modulepath = application
classpath = guava, joda-beans

The application developer can write the module declarations above, and
use them even though all the external dependencies are yet to be
modularised. It seems clear to me that the application developer has
modularised their application, even if not completely.

Given that this seems demonstrably false, I find the claim that
"application developers would have to wait" rather odd. This suggests
that something is perhaps not fully understood in the text above or
the partial proposal.

>   - We could solve that by keeping automatic modules and adding partial
>     modules, but then we'd have a more complex module system and a more
>     complex story to tell.

I agree with this. For me it either automatic or partial, not both.
And partial is a lot better in technical and community terms IMO as it
is a mechanism for reliable gradual migration. I still fail to see why
dumping the jars of the classpath on the modulepath and hoping it
works is a good strategy for migration - it seems like a bad short
cut.

Stephen


On 4 May 2017 at 18:39,  <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