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