Module names - related to #ModuleNameSyntax

[Stephen Colebourne]

On 10 October 2016 at 13:47, Andrew Dinn <adinn at redhat.com> wrote:
> On 10/10/16 12:47, Stephen Colebourne wrote:
>> At some later time, guava is modularised, but chooses the sensible
>> module name "com.google.guava". Now, the module foo (released as open
>> source to maven central) has the wrong module name for guava.
>
> I think this is where your argument does it's sleight of hand trick
> (intentional or not) that makes people believe in magic and ask for
> protection from it.
>
> Let's just rename your modular jar to foo-1.0.jar and see how the
> sleight of hand happens.
>
> You have a released module foo-1.0.jar that depends on and works with
> non-modular jar guava-19.0.jar. Now modular jar guava-20.0.jar is
> released. So, to cope with the update to guava you do what is normally
> done to cope with a dependency upgrade i.e. you release modular jar
> foo-1.1.jar which you have rebuilt to require com.google.guava.
>
> At this point foo-1.0.jar is not broken, nor is foo-1.1.jar. They work
> with the appropriate versions of guava.jar and any user of foo has to
> respect those dependencies (just like any other released artifact).
>
> Where is the actual problem?

The concept of upgrading a version of a dependency doesn't apply to
the JPMS as it does not have versions. ie. foo-1.0.jar does not depend
on guava-19.0, it depends on guava (version undefined). There should
be no reason to release foo-1.1 - the JPMS design expects later
versions to be able to be substituted on the module path (provided
they are compatible, which JPMS doesn't really check).

But more significantly try multiplying the problem described by a tree
of dependencies, where each is upgraded on different cycles. Releasing
your own new version of the top library is simply not a practical
solution to the problem.

I certainly think that automatic modules are a form of magic in the
JPMS, and we might be better off without them. But this thread is
about the more general problem of naming modules in a global world,
something where reverse domain naming has served Java extremely well.

Stephen