Multiple versions of a non-exported dependency

[Alan Bateman]

On 01/09/2016 13:29, David M. Lloyd wrote:

> It seems like there is no good reason why the application modules 
> aren't loaded with classloader-per-module now.  The platform stuff 
> could all be in one, but the application stuff?  Problems like this 
> are going to come up a lot otherwise; let's consider making that change. 
If we were just dealing with a graph of explicit modules they it may be 
an option, assuming you get over all the issues that arise when 
arranging visibility this way. You might remember "module mode" in the 
original exploratory phase of Project Jigsaw for example.

The issue is of course that there is lot more in picture, esp. when you 
have the unnamed module (= class path) reading all modules, also 
automatic modules that bridge to the class path (and so read the unnamed 
module). Then add upgradable modules into the picture, ... and you will 
quickly start to see there is a lot more to this, not to mind the risk 
of circular delegation.

So I think what we have ended up with sane and not difficult to explain. 
It favors migration and good interop over green field. Sure, there will 
be periodic complaints when people try to deploy modules with 
overlapping packages on the application module path. Anyone using Maven 
Shade Plugin and the like can continue to do this. Finally, it's not 
hard to create your own "launcher" that instantiates the configuration 
with Layer.defineModulesWithManyLoaders if you really want.

-Alan