Proposal: Fully Concurrent ClassLoading

[David Holmes]

On 15/12/2012 12:58 AM, Zhong Yu wrote:
> On Wed, Dec 12, 2012 at 5:48 PM, David Holmes<david.holmes at oracle.com>  wrote:
>> On 13/12/2012 1:51 AM, Zhong Yu wrote:
>>>
>>> If a class loader is declared fully concurrent, yet
>>> getClassLoadingLock() is invoked, what's the harm of returning a
>>> dedicated lock anyway, exactly like what's done before?
>>
>>
>> The whole point is to get rid of the lockMap and these lock objects.
>>
>> I could return a sentinel Object in all cases rather than null but that just
>> seems to encourage continued use of something that shouldn't be used with a
>> fully concurrent loader.
>>
>> Returning null versus throwing an exception is mostly a matter of style. I'd
>> want to hear from anyone who invokes getClassLoadingLock() on any of the
>> system classloaders to see which is preferable.
>
> Since this change will break some applications, the failure should be
> loud, with immediate and detailed information on what's going on, so
> the poor developers can fix the problem quickly.

Can you suggest any actual use of the result of getClassLoadingLock() 
that won't cause a NullPointerException if null is returned?

> I had the pleasure of implementing classloaders before, and I think it
> might be underestimated how many classloaders are actually out there.

The question is how many of them became parallel capable in Java 7 and 
out of those how many actually use the lockMap (via 
getClassLoadingLock()) themselves? Do you have any real data on that?

Can you even conceive a realistic example of how a custom loader might 
use the lock supplied by a parent loader?

Cheers,
David

> Zhong
>
>