Proposal: Fully Concurrent ClassLoading

[Peter Levart]

Hi again,

There might be a middle-ground variant. No registration API changes as 
described below. When ClassLoader X declares that it is fully-concurrent 
make it fully-concurrent. But if any superclass registered as only 
parallel-capable, provide getClassLoadingLock() locks nevertheless. Only 
if all the superclasses declare that they are fully-concurrent, make no 
lock map and make getClassLoadingLock() return null.

Regards, Peter

On 12/11/2012 10:20 AM, 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.
>
> 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
>