Automatic module names

[Robert Scholte]

On Fri, 27 Jan 2017 16:54:59 +0100, Robert Scholte <rfscholte at apache.org>  
wrote:

> On Fri, 27 Jan 2017 15:11:14 +0100, Stephen Colebourne  
> <scolebourne at joda.org> 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
> This matches proposal #2 and prevents all side effects of auto modules.
>
>>
>> - Define a clear mapping from Maven Central co-ordinates to module
>> name that includes the group, artifact and classifier
> Who/where to maintain this? By OpenJDK or by Maven Central? And are  
> projects in the lead to specify such mapping entries? I have my doubts  
> if this will work.
>
>>
>> - Provide a text file to JPMS that allows incorrect module names to be
>> mapped to the correct name
> Such information must be bundled as part of the module-info, otherwise  
> the next project using this jar as dependency will face the same  
> problems.
>
>>
>> - Publicly advise against using automatic modules for open source  
>> projects
> With Maven in mind, and especially the maven-compiler-plugin, this makes  
> sense when a module name cannot be mapped to a dependency, which means  
> it cannot decide if the jar should be on the classpath or modulepath.
>
>>
>> - Change rules of Maven Central to prevent modular jars being added
>> that depend on an automatic module
> Quality gateway of Maven Central is a continuous improving set of rules,  
> I can imagine that analyzing the module-info would become another rule
>
>>
>> - Allow requires clauses to have aliases - requires org.guava.guava OR  
>> guava.
> Keep in mind there can be indirect requirements which names must be  
> adjusted as well. I don't think you want to add them as new requirements  
> to your project just to be able to add an alias.
>
>>
>> - Allow modules to have aliases - module org.guava.guava AKA guava
> I assume that this means that org.guave.guava is the only official  
> modulename, 'guava' can only be used in case of automodules. So if there  
> is another jar with "module guava {}", it does not map.
>
>>
>>
>> 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.
>
> There is a conflict between "ease of transition" and "stability". What I  
> wonder is:
> Is it acceptable to start with:
>
> module org.joda.convert {
>   // no module yet:   requires guava;
> }

Let me reply to myself. Mark pointed me to a feature of automodules  
compared with classpath jars.
Classes on the classpath are not visible if you are compiling your modular  
project.
I've done a small test to ensure I did understand it correctly.

So my suggestion won't work right now, you need to specify guava, which I  
consider as a blocker. Developers are forced to refer to unnamed modules,  
even though nobody can ensure that the suggested name will become the  
actual name of the module. Developers must have the option to pick their  
own subset of requirements. And for library builders we want to enforce  
that they only use named modules.

thanks,
Robert

>
> This way at least all projects can start requiring org.joda.convert, and  
> in time the graph of requirements will automatically grow. Not being  
> ably to refer to unnamed modules is very well explainable.
>
> thanks,
> Robert
>
>>
>> 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