Automatic module names

[David M. Lloyd]

So far I haven't commented on automatic modules because while I don't 
see them as useful, I also didn't see them as harmful.  However this 
keeps popping up, so, see inline comments.

On 01/27/2017 08:11 AM, Stephen Colebourne wrote:
[...]
> 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).
[...]

> - Remove the automatic module concept altogether

This is my vote.  Automatic modules are meant to simplify migration by 
allowing "legacy" artifacts to be included in a modular environment. 
But in real use cases, it is often if not usually the case that manual 
intervention will be required anyway.  Therefore, automatic modules do 
not actually make things any easier (in fact they hide land mines around 
your deployment operation).  It makes more sense to create or use a 
provided tool to easily modularize a JAR by allowing its dependencies to 
be specified.  A system like Maven might allow such a modularization 
process to be largely automatic, thanks to the dependency information 
already at its disposal (though such a case *should* present a report to 
the user allowing them to spot any problems or potential problems that 
may arise from a particular generated wiring; in general, magic is bad 
if it isn't well-defined or easily validated).

As I've expounded on previously, on multiple occasions, it is highly 
unlikely that centrally deployed modules will be universally useful 
without manual work on the part of the consumer.  It is far better to 
make this process as clean, easy, and well-defined as possible than to 
"fudge" it using automatic modules, magical wiring, or anything else of 
the sort, which seems easy at first and then bites back later.

> 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.

This could be very useful.  But I think it should be a Maven function 
rather than adding this to the JPMS, forever.

-- 
- DML