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