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 identical?) 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 [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012111.html -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development https://www.sitepoint.com/java high-quality Java/JVM content http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx
