Proposal: Fully Concurrent ClassLoading

[Peter Levart]

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.

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