Alternatives to automatic modules as a concept
David M. Lloyd
david.lloyd at redhat.com
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
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