The critical missing pieces and a path forward

Remi Forax forax at
Mon May 8 17:41:26 UTC 2017

people are very creative with classloaders, do not using the delegation scheme as recommended is one example, that the reason why the module system can not use classloaders for itself, it will broke all applications created by creative people we're talking about.

As Mark said, there was a prototype of jigsaw that tries try to use classloaders for defining modules, i've tried to port one of my application on that prototype, it was an utter failure. I do not even imagine OSGI or JBoss Module working with that setup.


----- Mail original -----
> De: "David M. Lloyd" <david.lloyd at>
> À: "mark reinhold" <mark.reinhold at>
> Cc: jpms-spec-experts at
> Envoyé: Lundi 8 Mai 2017 18:38:07
> Objet: Re: The critical missing pieces and a path forward

> On 05/08/2017 09:57 AM, mark.reinhold at wrote:
> > [...]
>> This module system loads application modules into a single class loader
>> by default so that developers have one less behavioral difference to
>> worry about as they upgrade their components to explicit modules.  An
>> early prototype did load every module into its own loader by default.
>> With that we found that a fair bit of existing code -- not just code in
>> the JDK itself -- is written assuming that the grandparent of its loader
>> is the boot loader, that its loader (or perhaps its loader's parent) is
>> the thread-context loader, that code in nearby modules is in the same
>> loader, and so on.
> In addition to being an unusual time to suddenly start worrying about
> compatibility, this is very surprising to me as we have not seen this,
> including at a time when our main middleware product completely dropped
> hierarchical class loading back a number of years ago during Java 6 days
> (which is when I would have expected to see these problems crop up).  Do
> you have any public examples you can cite?
> --
> - DML

More information about the jpms-spec-observers mailing list