Multiple versions of a non-exported dependency

[David M. Lloyd]

On 09/01/2016 08:59 AM, Alan Bateman wrote:
> 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.

Risk?  If the modules don't have circular delegation then the class 
loaders won't; but anyway I don't understand *at all* why circular 
delegation in class loaders is a problem (we do this today and it has 
worked great since Java 7, and there's no particular magic necessary to 
do so).  And in any event circular delegation in modules *should* be 
allowed, full stop; there's no good reason not to allow it (especially 
given the very-super-eager-loading behavior of module layers).  Again we 
do this today and it's fine.

> So I think what we have ended up with sane and not difficult to explain.
> It favors migration and good interop over green field.

Yeah having the class path remain on the legacy application class loader 
is demonstrably better for interop.  But new modules?  Does that make sense?

> 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.

I think many people will do this.  The benefits of modules are 
diminishing if you don't actually get this level of isolation by 
default.  And I think that it's much harder to imagine a real interop 
problem that could arise from it than it is to imagine a real problem 
that will occur from not doing it.

Anyway using interoperability as an argument is very weak as long as 
"export dynamic *" or any variation thereof is considered to be an 
acceptable solution to #ReflectiveAccessToNonExportedTypes.  In order to 
have proper interoperability for any reflection-using or reflected 
module, you have to do this, which defeats the primary security measure 
of modules.  Isn't this a much more likely interop problem than putting 
modules (something that never existed before) into their own class loaders?

-- 
- DML