Alternatives to automatic modules as a concept

[Stephen Colebourne]

Automodules exist to provide a means for gradual migration from a
non-modular world to a modular one. Unfortunately, they have proven
controversial with most of the EG and Jigsaw list. This thread seeks
to bring together some of the proposals to remove automodules.

The key issue is that automodules force a module author to pick the
name of modules that they do not control. Note that while a better
module naming strategy (discussed elsewhere) reduces the potential for
issues, a module author should never, ever be asked to guess somebody
else's name. That is the fundamentally broken concept.

These are the possible alternatives that remove the need for guessing
a name that I can see (without changing JPMS so much that Java 9 is
delayed again):


1) Depend on a subset of modules

The basic concept of this option is that a module only needs to depend
on a subset of all their dependencies. They specify those dependencies
that are modularized, and depend on the classpath for the rest. When a
dependency is modularized, the next version of the module would
specify the module name that the dependency chose.
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-January/011109.html
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-February/000572.html

Three possible syntaxes for very similar semantics. References to
"classpath" would actually mean "classpath plus other modules in the
module graph":

1a) Requires classpath
(alternate names to "classpath" welcome)

// this depends on all jars in the classpath
module com.foo.main {
  requires com.foo.base;
  requires classspath;
}
// this only depends on the specified modules
module com.foo.main {
  requires com.foo.base;
  requires org.google.giava;
}

I'd expect there to be a "requires transient classpath" option if the
classpath has to be exposed transitively.

1b) Flexible modules
(alternate names to "flexible" welcome)

// this depends on all jars in the classpath
flexible module com.foo.main {
  requires com.foo.base;
}
// this only depends on the specified modules
module com.foo.main {
  requires com.foo.base;
  requires org.google.giava;
}

1c) Final modules
(alternate names to "final" welcome)

// this depends on all jars in the classpath
module com.foo.main {
  requires com.foo.base;
}
// this only depends on the specified modules
final module com.foo.main {
  requires com.foo.base;
  requires org.google.giava;
}


2) Require packages

http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-February/011189.html

Here a module expresses that it depends on a package, which may be in
a standard module or a jar file on the module path (a different form
of automodule which needs no name):

module com.foo.main {
  requires module com.foo.base;
  requires package com.google.guava;
  requires package com.google.guava.io;
}

This is simple and obvious, but requires IDEs and toold to do more
work than option 1 to keep the list of packages up to date. Note that
using "requires package" causes the module to transitively depend on
the classpath, as there is no way to determine what the required
package depends on.


3) Remove the concept of automodules entirely

Migration would be slower, but safer. Tooling might evolve to add
module-info dynamically as part of the build or runtime system, or by
editing all the jar files in Maven Central to have an auto-generated
module name.

Er, I can't think of a viable option 4.


---

Non-solutions
a) The status quo

The current plan requires module names to be guessed.

b) Aliasing
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-February/011171.html

module com.foo.main {
  requires com.foo.base;
  requires guava;
}
Command line --alias guava=com.google.guava

This fails as a solution because the module author was still asked to
make a guess as to the module name. Being able to fix the incorrect
guess later is a hack.

Similarly, this fails:

module com.foo.main {
  requires com.foo.base;
  requires guava OR com.google.guava;
}

as the module author is still guessing the module name, they just had
two chances to get it wrong instead of one.

c) Regex matching

module com.foo.main {
  requires module com.foo.base;
  requires *guava*;
}

This fails as a solution because the module author was still asked to
make a guess as to the module name.

d) Using maven central groupId-artfactId

There is no guarantee that a project will want to use their maven
coordinates for their module name.


---

My preference is option 1b as it is similar to the "open module"
concept we already have. But I'm fine with 2, 1a and 1c too 3 seems a
bit harsh.

Love to know if I've missed any options.
Stephen