Proposal: Fully Concurrent ClassLoading
david.holmes at oracle.com
Sat Dec 15 09:24:51 UTC 2012
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?
More information about the core-libs-dev