Huge implications of multiple class loaders for application modules

[David M. Lloyd]

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

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