Aliasing (automatic) modules

Nicolai Parlog nipa at
Sat Apr 8 11:35:19 UTC 2017

 Hi again,

so far most (all?) proposals for handling automatic module names tackled
the "what is the module's real name" aspect of this question but I have
seen none that would push the likelihood of the same dependency being
referenced by different names reasonably close to zero. As argued
elsewhere[1], I think this needs to be addressed without preventing the
publication of artifacts with such references.

I want to propose a feature allowing aliasing (automatic) modules again
because it gives consumers of the conflict a straight-forward way to
handle the problem. And because I am convinced that these problems will
eventually arise, I think the JDK should really give developers a way to
fix them locally.

A command line option, let's say `--alias-modules A=X`, maps module name
A to module name X. Every dependency on either A or X will be resolved
to X, implying that there must a module X in the universe of observable
modules. There can be several aliases for the same module
(`--alias-modules A=X,B=X`; X needs to be observable) and they can be
chained (`--alias-modules A=X,X=Y`; Y needs to be observable). Aliasing
would of course have to be applied to qualified exports, opens, and
similar mechanisms as well.

It might be worth adding the rule that no observable module must have an
aliased name. So for `--alias-modules A=X` there must be no observable
module A. This prevents ambiguity and would effectively prevent aliasing
platform modules. That might be a good thing because it looks like
aliasing and upgrading modules has quite some overlap (or is even

Unfortunately I could not come up with a way to limit aliasing to
automatic module names (in case that were desirable) without somehow
marking dependencies on automatic modules, likely in the module
declaration. If changing module declaration syntax is still on the
table, it could be changed so that dependencies on automatic modules
must be phrased as something like `requires automatic`.

The obvious semantics would be that only such requires clauses can be
fulfilled with automatic modules and that only such dependencies could
be aliased (this might make it prudent to phrase the aliasing option
accordingly, e.g. `--alias-automatic-modules`).

This could also be used to help developers in keeping their module
declarations clean: The compiler could emit a warning if a `requires
automatic` clause is fulfilled by a regular module.

 so long ... Nicolai



PGP Key:

        a blog about software development
        high-quality Java/JVM content
        Free and Open Source Software for the City of Dortmund


More information about the jigsaw-dev mailing list