JDK的SPI(Service Provider Interface)实践

     一个服务(service)通常指的是已知的接口或者抽象类，服务提供方就是对这个接口或者抽象类的实现，然后按spi标准存放到资源路径META-INF/services目录下，文件的命名为该服务接口的全限定名。如有一个服务接口com.test.Service，其服务实现类为com.test.ChildService，那此时需要在META-INF/services中放置文件com.test.Service，其中的内容就为该实现类的全限定名com.test.ChildService，有多个服务实现，每一行写一个服务实现，#后面的内容为注释，并且该文件只能够是以UTF-8编码。
    这种实现方式，感觉和我们通常的开发方式差不多，都是定义一个接口，然后子类实现父类中定义的方法，为什么要搞这么一套标准以及单独搞一个配置文件？这种方式主要是针对不同的服务提供厂商，对不同场景的提供不同的解决方案制定的一套标准，举个简单的例子，如现在的JDK中有支持音乐播放，假设只支持mp3的播放，有些厂商想在这个基础之上支持mp4的播放，有的想支持mp5，而这些厂商都是第三方厂商，如果没有提供SPI这种实现标准，那就只有修改JAVA的源代码了，那这个弊端也是显而易见的，也就是不能够随着JDK的升级而升级现在的应用了，而有了SPI标准，SUN公司只需要提供一个播放接口，在实现播放的功能上通过ServiceLoad的方式加载服务，那么第三方只需要实现这个播放接口，再按SPI标准进行打包成jar，再放到classpath下面就OK了，没有一点代码的侵入性。

如xml-parse等都属于spi，我自己实践了一下，示例如下：

定义接口

package spi;
/**
 * Service Provider Interface
 * META-INF\service\$interface full name
 *  内容为借口实现类全名
 * @author liwenj
 */
public interface Developer {
public String getPrograme();
}

 

 

实现接口

package spi;
public class JavaDeveloper implements Developer {
 
@Override
public String getPrograme() {
     return "Java";
}
 
}

 

实现接口的同时，需要在MANIFEST中声明实现

在META-INF\service目录下 创建文件，以接口全名为名，如"spi.Developer"

内容就是实现类的全名，可以存在多个

注意：在META-INF\service中声明好接口实现后，要打成一个jar包导入到工程的classpath中。jdk需要在Jar文件中的META-INF\service目录中搜索

 

使用实现

package spi;
import java.util.ServiceLoader;
public class DeveloperClient {
public ServiceLoader<Developer> serviceloader = ServiceLoader.load(Developer.class);
 
public static void main(String[] arg) {
DeveloperClient devClient = new DeveloperClient();
Developer dev = devClient.getDeveloper();
 
System.out.println(dev.getPrograme());
}
 
private Developer getDeveloper(){
Developer lastdev = null;
 
for(Developer dev : serviceloader) {
System.out.println("out." + dev.getPrograme());
lastdev = dev;
}
 
return lastdev;
}
}