hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader.
David M. Lloyd
david.lloyd at redhat.com
Thu May 24 07:34:59 PDT 2012
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
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.
More information about the jigsaw-dev