| 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 sun.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:
sun.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.
author:
Mark Reinhold
version:
1.11, 03/12/19
since:
1.3 | 