On Oct 4, 2012, at 10:14 AM, David Holmes <[email protected]> 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 :-) Paul.
