Coupling modules and class loaders

David M. Lloyd david.lloyd at redhat.com
Wed Oct 21 10:53:05 UTC 2015


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


More information about the jpms-spec-observers mailing list