hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader.

[David M. Lloyd]

On 05/23/2012 07:42 PM, Mandy Chung wrote:
> On 5/23/2012 9:51 AM, David M. Lloyd wrote:
>>
>> This change seems to me the wrong way around: since using null as an
>> argument to Class.forName() (and similar) still has to be supported,
>> why not simply have the base module class loader delegate to its parent?
>
> FWIW, the base module class loader does delegate to VM null loader in
> the implementation.
>
> In classpath mode, Class.forName() with a null class loader argument
> will load classes from the bootclasspath. In module mode, when
> Class.forName() with a null loader is called, do you expect it loads
> classes only in the base module or all classes from all jdk modules?

Well that's the big question.  From a purist point of view, it would 
make some sense (in module mode) for the null class loader to be 
existent but empty (or only consisting of classes from the 
bootclasspath).  In reality though I think that breaking the behavior 
that a null class loader loads JDK classes might be major trouble.

That's why I was suggesting a while ago that all of base in fact be a 
single physical module which could be optionally distributed piecewise, 
and use filtered down module aliases to represent the individual pieces 
of it.  This way all base modules are on the null/base class loader, you 
still are fully modularized in any practical sense, *and* you don't have 
to rewrite scads of JDK code.

I've found that the general expectation is that java.* things are 
available on the null class loader; javax.* things are not really 
expected to be.  So take that information for what it's worth.

>> This, in combination with "spoofing" the base module's
>> Class.getClassLoader() output, seems like it would suffice.
>>
>> On a related note, most standalone class loaders out in the wild will
>> in fact delegate to their parent. What does this mean when classes
>> that were a part of the core JDK are now in discrete (non-visible)
>> modules? I think this is a major weakness of retroactively
>> modularizing the core.
>
> In classpath mode, existing application and class loaders should work as
> it is today. The platform modularization should be transparent to the
> classpath mode applications/class loader.
>
> In module mode, a relevant question is what module do classes loaded by
> the non-module
> class loader belong to? What types are visible to that non-module class
> loader?

I don't think standalone class loader classes should belong to any 
module.  getModule() == null.  A module is a specialization of a class 
loader, not a replacement.

> One initial proposal is to have classes loaded by a non-module class
> loader belong to the module in which that class loader is created.
> Therefore, all types visible to the module will also be visible to that
> non-module class loader. Details are yet to be fleshed out and prototyped.

If a standalone class loader delegates to, or is a child of, a module 
class loader, then yes this will happen naturally.  In the end it will 
be up to the class loader as it always has full control.

-- 
- DML