Automatic module names

[Alan Bateman]

On 03/02/2017 11:44, 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.
I think automatic modules are critical to migration, otherwise things 
move at the pace of the slowest project (which might be 0km/h in case of 
unmaintained projects). A lot of the discussion here has been on the 
naming but automatic modules but the other important benefit of 
automatic modules is that they support bridging to the class path.

As regards the example naming clash then these two projects might 
already get complaints over their poor choice of artifacts, esp. when 
artifacts for both projects are in same directory (say where someone 
distributes with all JAR files in a `lib` directory).

-Alan