A simple service-provider lookup mechanism. A service is a well-known set of interfaces and (usually abstract) classes. A service provider is a specific implementation of a service. The classes in a provider typically implement the interfaces and subclass the classes defined in the service itself. Service providers may be installed in an implementation of the Java platform in the form of extensions, that is, jar files placed into any of the usual extension directories. Providers may also be made available by adding them to the applet or application class path or by some other platform-specific means.

In this lookup mechanism a service is represented by an interface or an abstract class. (A concrete class may be used, but this is not recommended.) A provider of a given service contains one or more concrete classes that extend this service class with data and code specific to the provider. This provider class will typically not be the entire provider itself but rather a proxy that contains enough information to decide whether the provider is able to satisfy a particular request together with code that can create the actual provider on demand. The details of provider classes tend to be highly service-specific; no single class or interface could possibly unify them, so no such class has been defined. The only requirement enforced here is that provider classes must have a zero-argument constructor so that they may be instantiated during lookup.

A service provider identifies itself by placing a provider-configuration file in the resource directory META-INF/services. The file's name should consist of the fully-qualified name of the abstract service class. The file should contain a list of fully-qualified concrete provider-class names, one per line. Space and tab characters surrounding each name, as well as blank lines, are ignored. The comment character is '#' (0x23); on each line all characters following the first comment character are ignored. The file must be encoded in UTF-8.

If a particular concrete provider class is named in more than one configuration file, or is named in the same configuration file more than once, then the duplicates will be ignored. The configuration file naming a particular provider need not be in the same jar file or other distribution unit as the provider itself. The provider must be accessible from the same class loader that was initially queried to locate the configuration file; note that this is not necessarily the class loader that found the file.

Example: Suppose we have a service class named java.io.spi.CharCodec. It has two abstract methods:

public abstract CharEncoder getEncoder(String encodingName);

public abstract CharDecoder getDecoder(String encodingName);

Each method returns an appropriate object or null if it cannot translate the given encoding. Typical CharCodec providers will support more than one encoding.

If glassfish.io.StandardCodec is a provider of the CharCodec service then its jar file would contain the file META-INF/services/java.io.spi.CharCodec. This file would contain the single line:

  glassfish.io.StandardCodec    # Standard codecs for the platform

To locate an codec for a given encoding name, the internal I/O code would do something like this:

CharEncoder getEncoder(String encodingName) {
    for (CharCodec cc : ServiceFinder.find(CharCodec.class)) {
        CharEncoder ce = cc.getEncoder(encodingName);
        if (ce != null)
            return ce;
    }
    return null;
}

The provider-lookup mechanism always executes in the security context of the caller. Trusted system code should typically invoke the methods in this class from within a privileged security context.

ClassLoader cl = Thread.currentThread().getContextClassLoader();
return Service.providers(service, cl);