JDK的SPI

一个服务(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，我自己实践了一下，示例如下：

定义接口

Java代码  

1. package spi;  
2. /** 
3.  * Service Provider Interface 
4.  * META-INF\service\$interface full name 
5.  *  内容为借口实现类全名 
6.  * @author liwenj 
7.  */  
8. public interface Developer {  
9. public String getPrograme();  
10. }  

 

 

实现接口

Java代码  

1. package spi;  
2. public class JavaDeveloper implements Developer {  
3.    
4. @Override  
5. public String getPrograme() {  
6.      return "Java";  
7. }  
8.    
9. }  

 

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

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

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

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

 

使用实现

Java代码  

1. package spi;  
2. import java.util.ServiceLoader;  
3. public class DeveloperClient {  
4. public ServiceLoader<Developer> serviceloader = ServiceLoader.load(Developer.class);  
5.    
6. public static void main(String[] arg) {  
7. DeveloperClient devClient = new DeveloperClient();  
8. Developer dev = devClient.getDeveloper();  
9.    
10. System.out.println(dev.getPrograme());  
11. }  
12.    
13. private Developer getDeveloper(){  
14. Developer lastdev = null;  
15.    
16. for(Developer dev : serviceloader) {  
17. System.out.println("out." + dev.getPrograme());  
18. lastdev = dev;  
19. }  
20.    
21. return lastdev;  
22. }  
23. }