Reviewer and committer request for 7198496 (original) (raw)

David Holmes david.holmes at oracle.com
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 oracle.com> 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.

David

More information about the core-libs-dev mailing list