Reviewer and committer request for 7198496

Paul Sandoz paul.sandoz at
Wed Oct 3 13:37:23 UTC 2012

On Oct 3, 2012, at 3:17 PM, David Holmes <david.holmes at> wrote:

> Paul,
> On 3/10/2012 10:50 PM, Paul Sandoz wrote:
>> For the benefit of others; for some context see this recent thread:
>> Basically ServiceLoader is treating a null CL parameter as the system CL for loading the META-INF/services resources file and as the bootstrap CL for loading the classes of class names declared in those resource files.
>> Which also means that calls to:
>>   ServiceLoader.load(serviceInterface)
>>   ServiceLoader.load(serviceInterface, Thread.currentThread().getContextClassLoader());
>> Will behave oddly if the TCCL is null, from the JavaDoc of Thread.getContextClassLoader():
>>   Returns:
>>   the context ClassLoader for this Thread, or null indicating the system class loader (or, failing that, the bootstrap class loader)
> The @return doc for getContextClassLoader is wrong, or at best mis-leading. A null return does NOT indicate the system class loader (which is never null) - it simply means there is no CCL for that thread. If anything null would represent the bootstrap loader.


In the JDK i see code such as:

                Class c = Class.forName(className, true,Thread.currentThread().


        ClassLoader contextClassLoader =
        if (contextClassLoader == null) {
            contextClassLoader = ClassLoader.getSystemClassLoader();

The only way i can interpret that TCCL JavaDoc sanely is to assume "null" is overloaded to mean the caller should try to use system or bootstrap CL if possible, otherwise failing that the bootstrap CL.


More information about the core-libs-dev mailing list