Coupling modules and class loaders

[David M. Lloyd]

I realize now that I didn't notice this reply - my apologies.  Responses 
inline.

On 10/22/2015 01:53 AM, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "David M. Lloyd" <david.lloyd at redhat.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: jpms-spec-experts at openjdk.java.net
>> Envoyé: Mercredi 21 Octobre 2015 20:42:27
>> Objet: Re: Coupling modules and class loaders
>>
>> 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?
>
> JBoss Module, OSGI implementations, any applications that uses classloader to implement a kind of module-like isolation. All of these applications will not work if we choose a classloader based module implementation because each of them connect classloders in an incompatible way compared to the others.

This is actually untrue.  The JBoss OSGi implementation was successfully 
built on top of, and therefore compatible with, JBoss Modules, as is our 
Java EE class loading implementation.  The entire justification of class 
loader based modules is that they work with everything and with it, you 
can make everything work together.

>>> 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.
>
> no, there are 3 'times'.
> The build time, the link time (think jlink but perhaps it should be called the installation time and jlink renamed to jinstall) and the runtime.
> You can run with a different version of a dependency than at build time but the modules at installation time should be the same as the modules at runtime.
> So at installation time, you can check if you have several incompatible versions of the same module and transform the code to link them (or some of them) statically.

I don't really see how this relates to the run time implementation 
though.  Whether you use class loaders or some new construct within 
class loaders, the link time behavior could be the same.

>>> 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.
>
> If we forget one moment the issue about setAccessible of jigsaw, for most of the applications, it just works.
> For applications that already have a notion of modules at runtime, yes, the code need to be touched but as you said there is few frameworks like this so they can be updated by hand.
> Maybe JBoss Module requires less code/no code changes to support other applications but here we want to support is applications like JBoss Module.

If we used class loader based modules, we wouldn't even need JBoss 
Modules.  The JDK itself would be able to support OSGi, Java EE, and 
applications all in one interconnected space (even legacy extensions, a 
class path module, and command-line JARs with Class-Path references), 
just as the JBoss application servers are capable of doing today, and I 
think the majority of existing software (at least, that which you'd find 
on, say, Maven Central) would continue to work largely unchanged.

I've opened a discussion about accessibility in another thread.
-- 
- DML