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
