jar包的service Provider机制

官方描述：http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html

The META-INF directory

The following files/directories in the META-INF directory are recognized and interpreted by the Java 2 Platform to configure applications, extensions, class loaders and services:

• MANIFEST.MF

The manifest file that is used to define extension and package related data.

• INDEX.LIST

This file is generated by the new "-i" option of the jar tool, which contains location information for packages defined in an application or extension.  It is part of the JarIndex implementation and used by class loaders to speed up their class loading process.

• x.SF

The signature file for the JAR file.  'x' stands for the base file name.

• x.DSA

The signature block file associated with the signature file with the same base file name. This file stores the digital signature of the corresponding signature file.

• services/

This directory stores all the service provider configuration files.
这里指出了jar包的典型的目录结构。简单翻译:

META-INF目录中的下列文件和目录获得Java 2平台的认可与解释，用来配置应用程序、扩展程序、类加载器和服务：
• MANIFEST.MF：清单文件，用来定义与扩展和数据包相关的数据。
• INDEX.LIST：这个文件由JAR工具的新“-i”选项生成，其中包含在一个应用程序或扩展中定义的数据包的地址信息。它是JarIndex的一部分，被类加载器用来加速类加载过程。
• x.SF：JAR文件的签名文件。x代表基础文件名。
• x.DSA：这个签名块文件与同名基础签名文件有关。此文件存储对应签名文件的数字签名。
• services/：这个目录存储所有服务提供程序配置文件。

Service Provider

Overview

Files in the META-INF/services directory are service provider configuration files. 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.

A service is represented by an abstract class. 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.
 

Provider-Configuration File

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 newline-separated list of unique concrete provider-class names. Space and tab characters, 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.
 

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 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)ps.next();
           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.

介绍：

在META-INF/services目录下保存的是service provider的配置文件。 服务在应用中会是一个接口(更多的是抽象类)。
一个类服务器提供者实现了一个服务类。这类的服务提供类可以以扩展的形式发布到平台上。所以，jar文件引入了扩展目录，同样你也可以将服务提供者加入classpath提供访问。

服务都是表现为一个积累，而一个服务提供者通常是集成或实现了服务定义类。服务提供类通常不会像代理类一样为了正常提供服务而包含了请求者的许多信息。服务提供类一般倾向于高集成。
对这类服务提供类的唯一强制性要求就是必须有一个无参的构造函数。

provider 配置文件
META-INF/services目录作为provider配置文件的存放路径。provider配置文件中必须是全类名(包含package)。配置文件可以存在space tab 换行等字符,#作为注释。
注意：provider配置文件必须是以UTF-8编码。

 

总结：
      service provider机制为程序的动态扩展提供了契机，在应用中你可以针对接口编程，通过RTTI技术可以比较完美的解决程序之间的耦合性。相比于spring DIP机制，这也是一个不错的尝试，至少它不需要耦合spring包。