Coupling modules and class loaders

[forax at univ-mlv.fr]

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

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

regards,
Rémi

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