Coupling modules and class loaders

[Remi Forax]

Let's try to see the big picture, why people uses classloaders, either they want to be able to load/onload an application, have unconventional way to store bytecodes, do bytecode transformations, etc  or they want to isolate several parts of the application because those parts use incompatible versions of the same dependency. 

For the first reasons, this way to use classloaders is very dependent on the application and these applications tend to be very sensitive to the way class loaders are connected. People that design frameworks have come with very creative way of connecting classloaders and trying to force people that want modules to change the way classloaders work in their application will not work.

For the last reason, trying to solve problem of incompatible dependencies. I think it's a bad idea to try to fix a linking time issue with a runtime solution. The way to solve that issue at linktime is to link statically the module with one version of the dependency. This is done in Java by changing the bytecodes of the module and its dependency in order to rename the package and change the code that use this package. If we have an intelligent linker, or at least a pluggable one, this can be done at link time so there is no reason to use classloader for that at runtime.

I think that classloaders are the wrong mechanism for implementing modules because as jigsaw current prototype prove, you don't need them to provide stronger encapsulation and as it will slow down the adoption of modules because people will have to rewrite there fancy frameworks to be "module compatible".

regards,
Rémi

----- Mail original -----
> De: "David M. Lloyd" <david.lloyd at redhat.com>
> À: jpms-spec-experts at openjdk.java.net
> Envoyé: Mercredi 21 Octobre 2015 12:53:05
> Objet: Coupling modules and class loaders
> 
> There seems to be no user-facing benefit of modules as a separate
> entity/allowing multiple modules per class loader - in fact it already
> actively seems to cause trouble for users, due to package naming
> conflicts - so I'm thinking it's time we discuss this point specifically
> and directly.
> 
> I propose that modules are best defined as a specialization of class
> loaders.  Class loaders already have many of the properties that define
> a module: encapsulation, isolation, unique identity for packages.  In
> fact OSGi already uses this unit.  The only thing they are really
> missing is the ability to use a graph-like dependency structure, hence
> the specialization.
> 
> I believe this results in a superior design overall.  Risk is lowered
> because this approach is well-understood and used by multiple containers
> and vendors.  As far as I can ascertain, there are no requirements which
> cannot be met with this approach (there has been in the past an allusion
> to security requirements wherein certain modules are expected to appear
> to have a 'null' class loader; this is easily accomplished however).
> 
> What is the justification for the more complex Jigsaw approach?
> --
> - DML
>