ServiceLoader.load(Class, ClassLoader) bug
peter.levart at gmail.com
Mon Oct 1 17:00:41 UTC 2012
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).
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.
> 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:
>>> 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):
>>> - loader = cl;
>>> + loader = cl == null ? ClassLoader.getSystemClassLoader() : cl;
>>> Regards, Peter
More information about the core-libs-dev