ServiceLoader.load(Class, ClassLoader) bug

[Peter Levart]

Hi Paul,

It would be very strange code indeed that acted on the 
ServiceConfigurationError in a way that you describe. After all, the 
java.lang.Error hierarchy of throwables is reserved for things that 
should be "acted upon" only by fixing the code, isn't it?

This is also explicitly noted in the javadoc of the ServiceLoader:

"Design Note: Throwing an error in these cases may seem extreme. The 
rationale for this behaviour is that a malformed provider-configuration 
file, like a malformed class file, indicates a serious problem with the 
way the Java virtual machine is configured or is being used. As such it 
is preferable to throw an error rather than try to recover or, even 
worse, fail silently."

FWIW, I stumbled on the bug by chance in an application using Jetty 
servlet engine as an embedded component. The service that was to be 
loaded was a component of the Spring web application framework which 
passed  the "Web Context" CL to the ServiceLoader to load a component 
and that "Web Context" CL returned by embedded Jetty was null (probably 
because of miss-configuration of Jetty).

If ServiceLoader used System CL to load the class instead, the 
miss-configuration of Jetty would go unnoticed.

But that's not the situation that you are concerned about. You are 
concerned that a (badly written app) might end up loading "different" 
service implementation even though that might be the one that should be 
loaded (by the book).


Regards, Peter

On 10/01/2012 04:33 PM, Paul Sandoz wrote:
> Hi Peter,
>
> Thanks for reporting this.
>
> It would be helpful to know the original intent of the author, but i suspect this is a bug (even though null is commonly used to refer to the bootstrap CL).
>
> FWIW i cannot find any explicit cases in the JDK that relies on this behaviour to explicitly limit the loading of service provider classes to those in rt.jar, which would be kind of a pointless use of SL :-)
>
> I am inclined to think that fixing this is mostly harmless, since passing a null CL renders SL useless for anything but service provider classes in rt.jar, and there are so very few of those provider classes i.e. this issue is likely to have been mostly worked around by explicitly passing in a non-null CL, such as ClassLoader.getSystemClassLoader().
>
> However, I say mostly harmless because fixing this will change behaviour to no longer produce an error that would otherwise be acted on. This may be the case for libraries that use SL and the user passed a CL to the library and the library on error uses, for example. the thread context CL. Who knows, CL code can be very strange.
>
> Paul.
>
> On Sep 14, 2012, at 10:20 AM, Peter Levart <peter.levart at gmail.com> wrote:
>
>> I reported this as Bug ID: 7198496
>>
>> Regards, Peter
>>
>> On 09/13/2012 05:13 PM, Peter Levart wrote:
>>> Hi,
>>>
>>> The javadoc for java.util.ServiceLoader.load(Class service, ClassLoader loader) method says about it's parameters:
>>>
>>>      * @param  service
>>>      *         The interface or abstract class representing the service
>>>      *
>>>      * @param  loader
>>>      *         The class loader to be used to load provider-configuration files
>>>      *         and provider classes, or <tt>null</tt> if the system class
>>>      *         loader (or, failing that, the bootstrap class loader) is to be
>>>      *         used
>>>
>>> So one might think that calling:
>>>
>>>     ServiceLoader.load(service, null);
>>>
>>> is equivalent to:
>>>
>>>     ServiceLoader.load(service, ClassLoader.getSystemClassLoader());
>>>
>>>
>>> But it is not. Either this is a bug in ServiceLoader or javadoc has to be changed.
>>>
>>> If null is specified as ClassLoader then ServiceLoader locates META-INF/services/interface.name resources using system ClassLoader (using ClassLoader.getSystemResources), but loads implementation classes using bootstrap ClassLoader (using Class.forName(className, true, null)).
>>>
>>> If this is not the expected behaviour then the fix is simple (in the private constructor of ServiceLoader[217]):
>>>
>>> -    loader = cl;
>>> +   loader = cl == null ? ClassLoader.getSystemClassLoader() : cl;
>>>
>>>
>>>
>>> Regards, Peter
>>>
>>>
>>>
>>>