Proposal: Fully Concurrent ClassLoading

David Holmes david.holmes at
Tue Dec 11 09:29:02 UTC 2012

On 11/12/2012 7:20 PM, Peter Levart wrote:
> On 12/11/2012 03:55 AM, David Holmes wrote:
>>> Question on the source code: registerAsFullyConcurrent has confusing
>>> comment -
>>> do the super classes all need to be parallel capable? Or do the super
>>> classes all need
>>> to be FullyConcurrent? I assume the latter, so just fix the comments.
>> Actually it is the former. There's no reason to require that all
>> superclasses be fully-concurrent. Of course a given loaders degree of
>> concurrency may be constrained by what it's supertype allows, but
>> there's no reason to actually force all the supertypes to be
>> fully-concurrent: it is enough that they are at least all parallel
>> capable.
> Hi David,
> There is one caveat: if ClassLoader X declares that it is
> fully-concurrent and it's superclass Y is only parallel-capable, then X
> will act as fully-concurrent (returning null from
> getClassLoadingLock()). superclass Y might or might not be coded to use
> the getClassLoadingLock(). X therefore has to know how Y is coded. To be
> defensive, X could ask for Y's registration and declare itself as only
> parallel-capable if Y declares the same so that when Y is upgraded to be
> fully-concurrent, X would become fully-concurrent automatically. To
> support situations where the same version of X would work in two
> environments where in one Y is only parallel-capable and in the other Y
> is fully-concurrent, there could be a static API to retrieve the
> registrations of superclasses.

I don't quite follow this. What code in the superclass are you 
anticipating that the subclass will use which relies on the lock? Or is 
this just an abstract "what if" scenario?


> Or, to have less impact on future deprecation of old parallel-capable
> registration API, the fully-concurrent registration API:
> protected static boolean registerAsFullyConcurrent()
> might take a boolean parameter:
> protected static boolean registerAsFullyConcurrent(boolean
> downgradeToPrallelCapableIfAnySuperclassIsNotFullyConcurrent)
> and provide no accessible API to find out what the registration actually
> did (register as parallel-capable or fully-concurrent - return true in
> any case).
> Since all JDK provided ClassLoaders will be made fully concurrent, this
> might only be relevant if there is vendor A that currently provides only
> parallel-capable ClassLoader implementation and there is vendor B that
> subclasses A's loader and wants to upgrade and be backward compatible at
> the same time.
> Does this complicate things to much for no real benefit?
> Regards, Peter

More information about the core-libs-dev mailing list