Using non-parallel custom class loaders for Layer configurations

[David M. Lloyd]

On 09/09/2016 11:26 AM, Alan Bateman wrote:
> On 08/09/2016 23:29, David M. Lloyd wrote:
>
>> Is it not necessary that any class loader in use by a Layer must be
>> parallel-capable?  Otherwise it seems like deadlocks could occur in
>> certain situations when there are references that are cyclic with
>> respect to class loaders mapped by the mapping function.
> There aren't cycles in readability graph, at least not at construction
> time. They might arise later due to reflective use of addReads but that
> shouldn't change the class loader delegation graph. So I'm curious if
> you are actually running into an issue or not? I can easily come up with
> a mapping to loaders to force this but it would be unusual mapping.
>
> BTW: I'm not opposed to exposing isParallelCapable, just curious if this
> is something that you are actually running into or not.

No, I've only run into this with our module system which is separate 
from Jigsaw, but I was examining this code recently and I was surprised 
to see that Jigsaw did not take this into account.

I don't think there needs to be a readability cycle between modules for 
this to be a potential problem; there only has to be a cycle between 
class loaders.  So if you (for whatever reason) put half of your modules 
in one class loader and half in another, and those modules refer to one 
another, I think you might have a problem if those modules refer to one 
another and the class loaders are not parallel capable.  But like I said 
that's just a hypothesis.

-- 
- DML