Reviewer and committer request for 7198496

David Holmes david.holmes at
Thu Oct 4 09:34:55 UTC 2012

On 4/10/2012 6:52 PM, Paul Sandoz wrote:
> On Oct 4, 2012, at 10:14 AM, David Holmes<david.holmes at>  wrote:
>>> I am not sure i agree. The TCCL can be set to null and that has significance as per the JavaDoc:
>>>       * @param  cl
>>>       *         the context ClassLoader for this Thread, or null  indicating the
>>>       *         system class loader (or, failing that, the bootstrap class loader)
>>>       *
>>>       * @throws  SecurityException
>>>       *          if the current thread cannot set the context ClassLoader
>>>       *
>>>       * @since 1.2
>>>       */
>>>      public void setContextClassLoader(ClassLoader cl) {
>> Sorry but that is just the dual incorrect statement of what is in getContextClassLoader. It is not a meaningful description, in fact it is incorrect because null only ever means the bootstrap loader, never the system class loader - and the null can't mean two different things.
>> And what is "or failing that" supposed to mean?
> I presume it means if the system CL is null.
> I would interpret the JavaDoc as follows: if I set the TCCL to null on a thread i would expect any consumer of the TCCL for that thread to first use the system CL. Which matches the behaviour of how SL is documented.
>> These parts of the javadoc for get/setContextClassLoader are simply wrong.
> Wrong or not because of such JavaDoc developers have been coding using TCCL with certain expectations of "null" different to that of just meaning the bootstrap CL.
> How would you propose to fix it?

I don't see anything that actually needs fixing (apart from the 
javadoc). Anyone using getCCL has to expect null as a possibility and 
they are then free to proceed however they like. The obvious ways to 
proceed are as I outlined earlier:
- use current classloader
- use system loader
- use bootstrap loader

which is appropriate depends on the code that was using getCCL. Often 
the current loader will be either the system or bootloader so that 
narrows the options.

> Did i tell you i really dislike TCCL :-)

:) It was a necessary evil to handle dynamic loading from extensions.


> Paul.

More information about the core-libs-dev mailing list