Reviewer and committer request for 7198496

David Holmes david.holmes at
Thu Oct 4 09:44:11 UTC 2012

On 4/10/2012 7:19 PM, Paul Sandoz wrote:
> On Oct 4, 2012, at 10:44 AM, Chris Hegarty<chris.hegarty at>  wrote:
>>> 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?
>>> These parts of the javadoc for get/setContextClassLoader are simply wrong.
>> They should be non-normative statements in the method description to give general guidance as to the interpretation of null.
> If i had 10 service providers, for service interface MyIterface, in jars added on my class path and i had application code that did the following:
>    public static void main(String... args) throws Exception {
>      Thread.currentThread().setContextClassLoader(null);
>      int i = 0;
>      for (MyIterface mi : ServiceLoader.load(MyIterface.class)) {
>        i++;
>      }
>      System.out.println(i);
>    }
> What do you think should be the result of executing the above?

Is this just a thought experiment? I would expect whatever 
ServiceLoader.load said would happen. Now if I were inventing 
ServiceLoader.load then I might specify it to do the following:
a) use the Thread CCL; or if that is null then;
b) use the caller classloader

With correctly delegating loaders this could implicitly cover the system 
loader and bootstrap loader. If I were somewhat conservative I might 
explicitly use the system loader if (a) and/or (b) fail, but then you 
are trying to second-guess an unknown classloading strategy so it may 
not be worth trying too many variations here.

So in my implementation all those interfaces would be loaded from their 
jars on the classpath.


More information about the core-libs-dev mailing list