A compromise approach on module isolation

[Alan Bateman]

On 12/05/2017 21:38, Tony Printezis wrote:

> David, Remi, and all,
>
> I have a few questions (and a concern),
>
> - This seems like a straightforward change and I’m sure it must have been
> proposed in the past. And I guess it was rejected for specific reasons.
> What are the gotchas of this approach? I.e. Will it break some code? Will
> it require some code to be changed? And will it bake-in some behavior that
> we might not want in the long term?
>
> - (With my JVM/GC implementer hat on) I really don’t think launching a
> class loader per module is a great idea. There are overheads in the JVM for
> each class loader you introduce (performance - the GC has to do some extra
> work per class loader, footprint - there are data structures maintained per
> class loader and space could be wasted due to fragmentation in the meta
> space of each class loader). FWIW, at Twitter, most of our services do not
> use custom class loaders and we get a lot of benefit out of that. It’d be a
> step backwards for us if somehow our JVMs got bloated with potentially
> 1,000s of class loaders.
>
> - Using class loaders is one way to isolate modules. Has anyone considered
> alternatives? For example, doing automatic shading of non-exported packages
> in the JVM (lots of hand-waving here)?
>
FWIW, we've been encouraging the use of shading on jigsaw-dev for a long 
time. When it works then it eliminates a lot of the potential for issues 
that otherwise arise when someone takes a copy of a library to include 
in their own library.

In any case, and at a high-level, then this topic of isolation or 
interference can be viewed as a failure of class loaders. Going there 
would be a huge undertaking, esp. when you start to think about 
identity. At least in Project Jigsaw, we chose not to go there.

Using class loaders for isolation is of course possible and has always 
been possible via the API (there is even a convenience method in 
ModuleLayer to do just that). The discussion here is therefore around 
the application module path that you specify to the `java` launcher or 
to the JNI invocation API. So it's mostly a JDK issue rather than a JSR 
376 issue. Alternatives to the current simple implementation have of 
course been explored -- this includes spilling when there are 
conflicting packages or just assigning the explicit modules on the 
module path to their own class loader. As expected, it brings many 
issues to the surface, particularly around the interoperability the 
class path, upgraded modules, qualified exports, and issues with legacy 
APIs (esp. resources) that arise with changes to visibility. These all 
seem like issues to look at in the future and what we have in JDK 9 
today doesn't preclude this.

-Alan