The critical missing pieces and a path forward
forax at univ-mlv.fr
Mon May 8 17:40:45 UTC 2017
----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: "David M. Lloyd" <david.lloyd at redhat.com>
> Cc: jpms-spec-experts at openjdk.java.net
> Envoyé: Lundi 8 Mai 2017 16:57:36
> Objet: Re: The critical missing pieces and a path forward
> This module system loads application modules into a single class loader
> by default so that developers have one less behavioral difference to
> worry about as they upgrade their components to explicit modules. An
> early prototype did load every module into its own loader by default.
> With that we found that a fair bit of existing code -- not just code in
> the JDK itself -- is written assuming that the grandparent of its loader
> is the boot loader, that its loader (or perhaps its loader's parent) is
> the thread-context loader, that code in nearby modules is in the same
> loader, and so on. In a future release we can explore loading every
> application module into its own loader, and maybe even make that the
> default behavior over time, but for now a more conservative approach is
> (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 .)
I disagree, respectfully, but you shall not touch my classloaders ...
ClassLoaders are a user-defined construct, not something the platform should touch.
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.
> - Mark
More information about the jpms-spec-observers