The critical missing pieces and a path forward

mark.reinhold at mark.reinhold at
Mon May 8 19:25:05 UTC 2017

2017/5/8 10:40:45 -0700, Remi Forax <forax at>:
> 2017/5/8 7:57:36 -0700, mark.reinhold at
>> ...
>> (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


More information about the jpms-spec-observers mailing list