The critical missing pieces and a path forward

[mark.reinhold at oracle.com]

2017/5/8 10:40:45 -0700, Remi Forax <forax at univ-mlv.fr>:
> 2017/5/8 7:57:36 -0700, mark.reinhold at oracle.com:
>> ...
>> 
>> (If do you need to load a set of modules with each module in its own
>> class loader then you can arrange for that in just a few lines of code
>> via the API [8].)
> 
> I disagree, respectfully, but you shall not touch my classloaders ...
> ClassLoaders are a user-defined construct, not something the platform
> should touch.

I wouldn't dream of touching your class loaders!

I was just pointing out that there's a convenient API by which you can
arrange for per-module class loaders, in which case the loaders are
provided by the system.  If you want to provide your own loaders then
you can do that too, with a different API to which you pass a function
from module names to loaders [1].  It's up to you.

> The VM can be changed to do not use a dictionnary by classloader but
> uses a data structure that map a class name to a Class depending on
> the current resolved module, i.e. instead of ClassLoader -> String ->
> Class, ClassLoader -> Module -> String -> Class.  It's not simple and
> calls like Unsafe.defineClass will not work anymore (or becomes
> @CallerSensitive) because they lack the current module context.

I'm not sure why any of this would be necessray.

- Mark


[1] http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/ModuleLayer.html#defineModules-java.lang.module.Configuration-java.util.function.Function-