Multiple versions of a non-exported dependency
David M. Lloyd
david.lloyd at redhat.com
Thu Sep 1 14:35:01 UTC 2016
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?
More information about the jigsaw-dev