Automatic module names

Fri Jan 27 14:42:49 UTC 2017

 Hi!

This obviously echoes the concerns Robert Scholte and Brian Fox recently
voiced and by and large I agree. For the automatic module feature to
work reliably across the ecosystem, we must face the fact that different
libraries or frameworks will pick different names for automatic modules
and bake them into their released module descriptor.

Personally, I like the idea that automatic modules bridge from module
path to class path and prefer solutions that keep that feature intact
and overcome the problems have been pointed out. My 2cts on Stephen's
brainstormed ideas:

> - Remove the automatic module concept altogether
> - Publicly advise against using automatic modules for open source
>   projects

As I said, I think automatic modules are a good idea, and under the
assumption that we want to keep them, I would rule these ideas out.

> - Change rules of Maven Central to prevent modular jars being added
> that depend on an automatic module

Wow, that would be, err, strict and comes pretty close to breaking the
automatic module feature. Interestingly enough, though, the Maven team
could decide this on their own if they are not happy with the JPMS as it
is released in July.

> - Define a clear mapping from Maven Central co-ordinates to module
> name that includes the group, artifact and classifier

This is in line with Robert's proposal to read the pom.properties from
the JAR. While it looks like that would work for the vast majority of
cases, I'd find it weird to have a "conceptual dependency" up the stack,
from the JPMS spec to a build tool.

> - Provide a text file to JPMS that allows incorrect module names to be
>   mapped to the correct name

I think the idea of having the javac/java caller influence the names of
automatic modules one way or another (command line options would be
great, too) is a very good and approachable fix for this problem.

> - Allow requires clauses to have aliases - requires org.guava.guava
>   OR guava.
> - Allow modules to have aliases - module org.guava.guava AKA guava

I'm not sure about those as a fix for the problem at hand. They just
seem to make it less likely that these cases occur but can not rule them
out on their own.

That being said, modules having aliases would of course be a feature of
its own, which would modules allow to stand in for other modules.

TL;DR: I'm convinced automatic modules are a good feature but it is
severely threatened by everybody guessing their dependency's names.
Having the ability to locally fix bad guesses would provide a way out.

 so long ... Nicolai

On 27.01.2017 15:11, Stephen Colebourne wrote:
> Back in October, I raised the issue of modules names generally and for
> automatic modules specifically [1]. The short thread came to no
> conclusion, but recent threads have again raised similar problems. The
> problem is that automatic modules have magical name creation from a
> filename, which is brittle and unlike anything else in Java.
> 
> I also recently looked at the Joda-Convert and Joda-Beans libraries,
> to see if I could add module-info in preparation for Java 9. I quickly
> backed away, again because of the same issue. Put simply, I am
> unwilling to write a module-info file that refers to a dependency that
> is not yet a module. And I have to advise all open source projects to
> do the same. Given this, there can be no simple migration to the JPMS
> for open source projects. Each open source project must wait for all
> its dependencies to migrate to JPMS (by adding a module-info and
> publishing to Maven Central).
> 
> The issue is clear. If I write this:
> 
> module org.joda.convert {
>   requires guava;
> }
> 
> where guava is an automatic module, I am locking in the name of the
> guava dependency, something that I do not control. The name "guava" is
> just a guess. The guava authors might choose "com.google.guava" or
> something else entirely.
> 
> In a closed system of modules, ie. a private application, automatic
> modules are fine, because the requires clause can be changed if it
> turns out the guess was wrong. But once published as an open source
> project to Maven Central or elsewhere, the guess cannot be fixed if it
> is wrong (without releasing a new version of the library, which is not
> an acceptable solution).
> 
> I also strongly believe that module names cannot be flat and
> unstructured, such as "joda-convert" or "guava". They must have
> structure, such as the domain name or a Maven-style group name
> "org.joda.convert" or "org.joda:joda-convert". The potential for
> clashes has been shown by the Maven team [2].
> 
> Some brainstormed possible changes:
> 
> - Remove the automatic module concept altogether
> 
> - Define a clear mapping from Maven Central co-ordinates to module
> name that includes the group, artifact and classifier
> 
> - Provide a text file to JPMS that allows incorrect module names to be
> mapped to the correct name
> 
> - Publicly advise against using automatic modules for open source projects
> 
> - Change rules of Maven Central to prevent modular jars being added
> that depend on an automatic module
> 
> - Allow requires clauses to have aliases - requires org.guava.guava OR guava.
> 
> - Allow modules to have aliases - module org.guava.guava AKA guava
> 
> 
> Given that applications can depend on libraries that haven't been
> released in years, this has the potential to be a critical problem for
> the ecosystem. My preference remains to define a clear mapping from
> the widely adopted Maven Central naming strategy to JPMS modules.
> Ideally, this would be a formal group concept in the JPMS, something
> that I believe is sorely lacking.
> 
> Stephen
> 
> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009631.html
> [2] http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2017-January/000707.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