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
