Multiple versions of a non-exported dependency

cowwoc cowwoc at
Wed Aug 31 20:15:50 UTC 2016


Thank you for the clarification.

I am a bit confused by your assertion... If you wanted to introduce 
first-class versions in JDK 10, how would you do so (without breaking 
backwards compatibility) in light of this format?

module {
     *requires*  org.baz.qux;


On 2016-08-31 4:09 PM, Alex Buckley [via jigsaw-dev] wrote:
> On 8/31/2016 12:51 PM, cowwoc wrote:
> > I agree that the situation is better, but not by much. Developers
> > routinely run across transitive dependencies that are incompatible with
> > each other. You seem to be under the impression that this a rare
> > occurrence or only occurs in the context of web containers, but this is
> > simply not the case.
> We're not under this impression at all. The problem is that the cost of
> solving incompatible indirect dependencies is high -- it would mean
> introducing first-class versions and changing the class loading
> characteristics of regular ('java'-launched) applications. Project
> Jigsaw chose a long time ago to let tools handle the version selection
> problem while it pursues other areas, namely strong encapsulation and
> "modules all the way down" (the modular JDK). I see no reason why a
> future project that wanted to introduce first-class versions couldn't do
> it on top of JDK 9.
> Alex
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the 
> discussion below:
> To unsubscribe from Multiple versions of a non-exported dependency, 
> click here 
> <>.
> <> 

View this message in context:
Sent from the jigsaw-dev mailing list archive at

More information about the jigsaw-dev mailing list