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
