Coupling modules and class loaders

[mark.reinhold at oracle.com]

2015/10/21 3:53 -0700, david.lloyd at redhat.com:
> ...
> 
> 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.

Class loaders do not provide strong encapsulation.  How do you propose to
extend them to do so?

> ...
> 
> What is the justification for the more complex Jigsaw approach?

One developer's complexity is another's simplicity.

The primary motivation is, as Rémi noted, to make it easy for existing
applications that use class loaders in sophisticated (and sometimes very
strange) ways to adopt modules.  If the maintainers of such applications
must make deep changes to their class-loading architectures in order to
support modules then some of them simply won't bother.

The fact that OSGi and JBoss have successfully used class loaders to
implement module systems that are capable of loading a wide variety of
existing artifacts is interesting.  It does not, however, imply that all
existing applications can be converted to use the class-loader-per-module
approach, nor that they should be forced to do so.  The proposed design
therefore neither mandates nor forbids that approach.

(See also my previous reply on this topic [1].)

- Mark


[1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2015-March/000068.html