Coupling modules and class loaders

[David M. Lloyd]

On 10/21/2015 12:11 PM, Remi Forax wrote:
> 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.

I don't think that the reasons users use class loaders really has any 
relevance here; I'm looking at the raw capabilities of class loaders and 
how they fit in to the requirements we have, and as it happens, they fit 
very well.

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

Only rare and highly specialized frameworks tend to define their own 
class loaders.  It has been proven repeatedly over the past several 
years (by us and by others) that most popular existing artifacts and 
projects already deal with class loaders in a manner which is completely 
compatible with class loader based modules.  So I'm not quite sure what 
you're driving at - do you have an example of something that would not 
work with class loader based modules?

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

Are you arguing that there are no cases where you want to run with a 
different version of a dependency than the one you built against?  I 
would refer you to just about any real world software deployment for an 
unlimited number of counter-examples.

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

Actually I believe your logic is exactly backwards.  We (Red Hat) have 
already been able to prove that very many existing frameworks can use 
our existing class loader based module solution without *any* 
modification, *because* they already use class loaders in a reasonable 
way to find classes and resources.  On the other hand, the current 
Jigsaw prototype inevitably implies that module adoption *will* be 
slowed down because in order to become module aware, you have to add 
extra code to recognize Modules and all that goes with them, above and 
beyond all the existing (and perfectly adequate and functional) code 
which uses class loaders for that purpose already today.

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

-- 
- DML