Coupling modules and class loaders

[mark.reinhold at oracle.com]

2015/12/10 7:39 -0800, david.lloyd at redhat.com:
> On 12/09/2015 07:27 PM, mark.reinhold at oracle.com wrote:
>> 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?
> 
> Sure they do - here are some ways:
> 
> * Package-private and protected members in one class loader are 
> inaccessible to packages in another class loader, even if the package 
> has the same name.

(Yes, that's strong encapsulation, but not strong encapsulation of modules
 or of module-like entities, which is what I meant.)

> * Run-time linkage is strongly encapsulated by class loader boundary; I 
> can declare a public type that nevertheless cannot be linked against by 
> anyone, if the class loader denies such access.  There are several use 
> cases for this.

That is encapsulation of a sort, but it's not strong since it works
differently with respect to reflection (which, yes, is the approach that
you advocate).

>>> ...
>>> 
>>> What is the justification for the more complex Jigsaw approach?
>> 
>> One developer's complexity is another's simplicity.
> 
> Fair enough, that was definitely a subjective assessment.
> 
>> 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.
> 
> I don't think they would though.  Even in the complete compatibility 
> case, the "flat classpath" module could and would still just be one 
> module with the whole class path on it, which would be not unlike Ye 
> Olde Application Class Loader, while still allowing the forward 
> migration path of adding real module dependencies to the ugly legacy 
> class path.  ...  If people are doing weird/nasty/ugly stuff with class 
> loaders, they would certainly be free to continue to do so if they want; 
> the per-class loader idea does not necessarily require that the module 
> class loader class be final, nor does it forbid it from being used as a 
> parent or delegate, unless you're thinking of something else?

What I'm thinking of is an existing application with its own non-trivial
class-loader architecture which, due to compatibility constraints, cannot
be changed.  If at least one of its class loaders loads classes from
logically-distinct components that are later converted into corresponding
modules then upgrading the application to load those components as
modules would, under your approach, require replacing that one class
loader with many class loaders, which would break compatibility.

Imagine, e.g., a Java EE application server that loads implementations of
all the standard EE components using one class loader.  Imagine further
that existing users (for good or for ill) depend upon that.  If a future
version of Java EE defines those components as modules then the only way
to arrange for this app server to load them as such would be to change
its class-loader architecture in a way that would break existing uses.

(This is, roughly, the situation with Oracle's WebLogic app server, as
 I've mentioned previously.)

>> 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.
> 
> I think we probably would not be able to put bounds on this without 
> enumerating specific use cases/behaviors (especially those that would 
> fail in this situation but not in the other), as I haven't encountered 
> nor been able to imagine a situation that would fail solely due to the 
> introduction of class loader based modules.

See above.

- Mark