Huge implications of multiple class loaders for application modules

[Gregg Wonderly]

> On Apr 25, 2017, at 8:44 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> On 04/25/2017 08:31 AM, Alan Bateman wrote:
>> On 25/04/2017 14:16, Michael Nascimento wrote:
>> 
>>> :
>>> and also the fact
>>> packages must be defined by a single module even if they are not
>>> exported,
>>> because it was considered nearly impossible to track in real world
>>> scenarios.
>>> 
>> Keep in mind that this is not a module system limitation, instead it is
>> just a consequence of defining all modules on the application module
>> path to the application class loader. Containers or applications using
>> the API doing dynamic configurations and creating module layers can put
>> modules in their own namespace to avoid conflicts between concealed
>> packages.
>> 
>> Someday then we might get to the point where modules on the application
>> module path could be assigned to different class loaders but it has huge
>> implications and would take an entire release to shake out issues.
> 
> I tend to disagree with the assertion that there would be huge implications.  Libraries and applications have been coping with multiple class loaders for many, many years, so this nothing new for them.  There are no real compatibility implications, as the JPMS ecosystem does not yet exist.  There are certainly no detrimental security implications (on the contrary, security should be marginally improved in the security manager situation as getting class loaders for other classes requires special permissions).

The real question is how are those ClassLoaders related.   Do they have a common parent ClassLoader using the current hierarchical class loading scheme so that there would be at least one common class loader for shared classes, or are we talking about creating a virtual loader environment that looks more like JavaEE or other “container” environments where one could count on ClassLoader separation keeping any “static” class data from being visible to more than a single one of these ClassLoader instances.

I use a tree based ClassLoader system in most of my applications which have plugins or other disconnected ClassLoading environments, and there will typically be a common ClassLoader parent between those ClassLoader instances and the java runtime.

This mechanism along with a SecurityManager provides a great deal of separation and isolation for my applications.

Gregg

> What exactly *are* the huge implications of this approach?  My attempts to get to the bottom of this on the spec experts list have gotten nowhere, so hopefully I'll have better luck here.
> 
>> BTW: The reasons why there are conflicts between concealed packages is a
>> good discussion point for another thread.
>> 
>> -Alan
> 
> -- 
> - DML