Still driving off the cliff

[Rémi Forax]

On 02/24/2012 06:26 PM, David M. Lloyd wrote:
>> With Jigsaw then it's usually a 1-1 mapping between module and class
>> loaders but we do have complications in the platform and it remains to
>> be seen where that goes. In addition I'm not sure where the class loader
>> relationship will be specified or not.
>
> The *only* reason I can see that Jigsaw doesn't mandate that a module 
> is a class loader is a module is so that platform classes can return 
> "null" to getClassLoader and yet still be called "modules".
>
> This is such a very thin foundation on which to base decisions such as 
> redefining what a module *is*, and consequently requiring two *modes* 
> of operation (doesn't that seem really awful to anyone else?).  If the 
> platform *must* be considered a single class loader then it shouldn't 
> be considered to be multiple modules - more like a single module with 
> some optionally available "features".  With this simple change you 
> don't need to have a "compatibility mode" to run old-style 
> applications, and you can consequently allow users to leverage a 
> *huge* body of prior work. 

There are lot of program like profilers, debuggers, agents etc
that relies on the fact that there is a way to separate the platform 
classes from
the application classes, this is usually done by checking if 
getClassLoader returns null
on a class.
If you break this assumption a lot of code will just break.
So even in a module world, you need a way to separate platform code from 
application code
(it should be better to even have a system which is able to separate the 
application, from the container,
from the platform).

I agree with David that we should not have a compatibility mode (at 
runtime).
Instead of having getClassLoader() returning a module class loader, 
getClassLoader() should still
return null for the platform class and jigsaw should add a new method 
called getModuleClassLoader()
that returns the module class loader.

Rémi