Alternatives to automatic modules as a concept

David M. Lloyd david.lloyd at
Thu Mar 16 16:21:59 UTC 2017

On 03/16/2017 10:48 AM, Stephen Colebourne wrote:
> 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):
> 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.

Indeed, it would be relatively easy to introduce a tool that would 
assemble an arbitrary set of JARs into a module graph, using a 
configuration descriptor for only the most advanced cases (pruning the 
service list, specifying reflection capabilities if they are more 
specific than "open all").  Such a tool would be superior to automatic 
modules in many ways.

This approach has other important advantages: zero magic (particularly 
if a tool can describe what it has done concisely), and choice of 

Even as I was writing this, a colleague of mine sent me a message that 
he has already independently created such a tool.  The URL is:

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

4) Support a mode of operation where the descriptor is external to the 
module content.

Containers are already going to be doing this anyway after all.  This is 
similar, in a way, to option 3 where tooling (or a person, if we can 
ever break away from this idea of requiring bytecode for this purpose) 
would be able to establish the modular environment without modifying the 
artifacts.  This is a model that we use today with success.


More information about the jigsaw-dev mailing list