The critical missing pieces and a path forward

[forax at univ-mlv.fr]

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: jpms-spec-experts at openjdk.java.net
> Envoyé: Lundi 8 Mai 2017 21:25:05
> Objet: Re: The critical missing pieces and a path forward

> 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 necessary.

allow non exported packages with the same name in different modules, allow several modules with different versions if not in the same transitive dependency set.  

> 
> - Mark
>

Rémi