On Sat, Dec 15, 2012 at 3:24 AM, David Holmes <david.hol...@oracle.com> wrote:
> On 15/12/2012 12:58 AM, Zhong Yu wrote:
>>
>> On Wed, Dec 12, 2012 at 5:48 PM, David Holmes<david.hol...@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'm saying a more specific exception could be more helpful than NPE,
for example, UnsupportedOperationException("getClassLoadingLock() not
supported in a fully concurrent class loader")
>> 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
>>
>>
>
