Reviewer and committer request for 7198496

Paul Sandoz paul.sandoz at
Thu Oct 4 08:52:52 UTC 2012

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?

Did i tell you i really dislike TCCL :-)


More information about the core-libs-dev mailing list