Automatic module names

[David M. Lloyd]

I think one option we should consider is to perhaps disable automatic 
modules for 9 and revisit the idea for 10, as it's late in the day and 
still clearly not settled.

On 02/03/2017 05:44 AM, Robert Scholte wrote:
> Hi Nicolai,
>
> let's consider that my project depends on the following dependencies:
> com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed.
>
> I somehow want to have them both as requirements:
> module M.N {
>   requires static library; // com.foo.bar:library
>   requires library; // com.acme:library
> }
>
> How can I define that the 'requires static library' should be mapped to
> com.foo.bar:library:1.0 on the modulepath, while 'requires library'
> should be mapped to com.acme:library:2.3.1
>
> One ugly solution would be:
>   requires static library containing com.foo.bar.baz.SomeClass;
>   requires library containing acme.AnotherClass;
>
> We should really wonder if ease-of-transition is worth the minefield
> we're creating with the introduction of automodules. IMHO all options
> we're trying to add to keep automodules will only over-complicate
> things, not even being sure if all edges are covered.
>
> thanks,
> Robert
>
> On Thu, 02 Feb 2017 12:28:13 +0100, Nicolai Parlog <nipa at codefx.org> wrote:
>
>>  Hi everyone,
>>
>> after thinking about this a little longer, I came to the conclusion that
>> compile-time/launch-time aliasing might be the only way out of this (at
>> least the only I could come up with) that keeps automatic modules alive
>> and does not introduce a conceptual dependency on Maven.
>>
>> The idea:
>>
>> 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 to emit a warning if a `requires
>> automatic` clause is fulfilled by a regular module.
>>
>> I would love to hear some thoughts on this idea, even if it considered
>> to be stupid, impractical,etc. :)
>>
>>  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
>>>
>>>

-- 
- DML