On 10/10/16 12:47, Stephen Colebourne wrote:
> "At JavaOne I asked a question about the naming standards for modules
> given that we have automatic modules.
>
> The scenario is as follows:
> - an open source module foo that depends on Google guava
> - guava has not yet been modularised
> - guava is provided by jar file guava-19.0.jar and used as an automatic module
> - foo declares "requires guava", where "guava" is a module name
> derived from the jar file name
>
> 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?
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
