Save This Page
Home » openjdk-7 » sun » misc » [javadoc | source]
public final class: Service [javadoc | source]
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 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 is a provider of the CharCodec service then its jar file would contain the file META-INF/services/ This file would contain the single line:    # Standard codecs for the platform
To locate an encoder for a given encoding name, the internal I/O code would do something like this:
  CharEncoder getEncoder(String encodingName) {
      Iterator ps = Service.providers(CharCodec.class);
      while (ps.hasNext()) {
          CharCodec cc = (CharCodec);
          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.
Method from sun.misc.Service Summary:
installedProviders,   providers,   providers
Methods from java.lang.Object:
clone,   equals,   finalize,   getClass,   hashCode,   notify,   notifyAll,   toString,   wait,   wait,   wait
Method from sun.misc.Service Detail:
 public static Iterator installedProviders(Class service) throws ServiceConfigurationError 
    Locates and incrementally instantiates the available providers of a given service using the extension class loader. This convenience method simply locates the extension class loader, call it extClassLoader, and then does
      return Service.providers(service, extClassLoader);
    If the extension class loader cannot be found then the system class loader is used; if there is no system class loader then the bootstrap class loader is used.
 public static Iterator providers(Class service) throws ServiceConfigurationError 
    Locates and incrementally instantiates the available providers of a given service using the context class loader. This convenience method is equivalent to
      ClassLoader cl = Thread.currentThread().getContextClassLoader();
      return Service.providers(service, cl);
 public static Iterator providers(Class service,
    ClassLoader loader) throws ServiceConfigurationError 
    Locates and incrementally instantiates the available providers of a given service using the given class loader.

    This method transforms the name of the given service class into a provider-configuration filename as described above and then uses the getResources method of the given class loader to find all available files with that name. These files are then read and parsed to produce a list of provider-class names. The iterator that is returned uses the given class loader to lookup and then instantiate each element of the list.

    Because it is possible for extensions to be installed into a running Java virtual machine, this method may return different results each time it is invoked.