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

[Jesse Glick]

On 05/23/2012 08:42 PM, Mandy Chung wrote:
> have classes loaded by a non-module class loader belong to the module in which that class loader is created

How do you determine "in which" module a ClassLoader is created? You cannot check the implementation class because plenty of code creates a plain URLClassLoader. And 
checking the call stack in effect when the ClassLoader constructor was called is unreliable.

> all types visible to the module will also be visible to that non-module class loader

This cannot be right. While most existing class loaders do delegate to one "parent", some delegate to multiple parents, some deliberately avoid delegating to anything 
more than the bare minimum bootstrap class loader (e.g. to implement something akin to an "isolate"), and some have a hybrid policy impossible to categorize.

The default proposal should be that a non-module class loader behave as it does today:

1. Those types are visible to it which its loadClass can load (without defining), whatever that method might do.

2. Those types are accessible which are visible, and either public or otherwise accessible according to Java 7 language rules (e.g. in the same non-sealed package).

Of course it would be nice to further restrict accessibility by adding a method to ClassLoader:

   /** Assuming this loader can load {@code type}, and it is accessible by premodule language rules, should it still be accessible? By default, yes. */
   protected boolean canAccess(Class<?> type) {return true;}

which ModuleClassLoader would then override to check exports, and a custom ClassLoader written against JDK 8 APIs could also override to help support third-party module 
systems. (Even nicer would be to pass AccessibleObject rather than Class<?> as the parameter, permitting the module system to export or hide individual elements such as 
methods if it so desires.)