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
