Alternatives to automatic modules as a concept

[David M. Lloyd]

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

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: 
https://github.com/moditect/moditect

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

-- 
- DML