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
