On 10 October 2016 at 13:47, Andrew Dinn <ad...@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
