Which of the three SPI mechanisms of JDK/Dubbo/Spring is better?

Like it first, then watch it, develop a good habit

SPI is called Service Provider Interface, which is a service discovery mechanism. The essence of SPI is to configure the fully qualified name of the interface implementation class in a file, and the service loader reads the configuration file and loads the implementation class. This can dynamically replace the implementation class for the interface at runtime. Because of this feature, we can easily provide extended functions for our programs through the SPI mechanism.

This article is mainly an introduction to features & usage, and does not involve source code analysis (the source code is very simple, I believe you will understand it at a glance)

What is the use of SPI?

For example, now we have designed a brand new log frame: super-logger . By default, an XML file is used as the configuration file of our log, and an interface for configuration file parsing is designed:

package com.github.kongwu.spisamples;

public interface SuperLoggerConfiguration {
    void configure(String configFile);
}

Then come to a default XML implementation:

package com.github.kongwu.spisamples;

public class XMLConfiguration implements SuperLoggerConfiguration{
    public void configure(String configFile){
        ......
    }
}

Then when we initialize and parse the configuration, we only need to call this XMLConfiguration to parse the XML configuration file.

package com.github.kongwu.spisamples;

public class LoggerFactory {
    static {
        SuperLoggerConfiguration configuration = new XMLConfiguration();
        configuration.configure(configFile);
    }
    
    public static getLogger(Class clazz){
        ......
    }
}

This completes a basic model, which seems to be no problem. But the scalability is not very good, because if I want to customize/extend/rewrite the parsing function, I have to redefine the entry code, and the LoggerFactory has to be rewritten, which is not flexible enough and too intrusive.

For example, if the user/user wants to add a yml file as a log configuration file, then only need to create a new YAMLConfiguration and implement SuperLoggerConfiguration. But... how to inject? How to use the newly created YAMLConfiguration in LoggerFactory? Is it possible that even LoggerFactory has been rewritten?

If you use the SPI mechanism, this matter is very simple, and you can easily complete the expansion function of this entry.

Let's first take a look at how to use JDK's SPI mechanism to solve the above scalability problem.

JDK SPI

A SPI function is provided in the JDK, and the core class is java.util.ServiceLoader. Its function is to obtain multiple configuration implementation files under "META-INF/services/" through the class name.

In order to solve the above problem expansion, we are now in META-INF/services/ create a next com.github.kongwu.spisamples.SuperLoggerConfiguration file (no extension). There is only one line of code in the file, that is our default com.github.kongwu.spisamples.XMLConfiguration (note that multiple implementations can also be written in one file, separated by carriage return)

META-INF/services/com.github.kongwu.spisamples.SuperLoggerConfiguration:

com.github.kongwu.spisamples.XMLConfiguration

Then get the implementation class of our SPI mechanism configuration through ServiceLoader:

ServiceLoader<SuperLoggerConfiguration> serviceLoader = ServiceLoader.load(SuperLoggerConfiguration.class);
Iterator<SuperLoggerConfiguration> iterator = serviceLoader.iterator();
SuperLoggerConfiguration configuration;

while(iterator.hasNext()) {
    //加载并初始化实现类
    configuration = iterator.next();
}

//对最后一个configuration类调用configure方法
configuration.configure(configFile);

Finally, adjust the initial configuration method in LoggerFactory to the current SPI method:

package com.github.kongwu.spisamples;

public class LoggerFactory {
    static {
        ServiceLoader<SuperLoggerConfiguration> serviceLoader = ServiceLoader.load(SuperLoggerConfiguration.class);
        Iterator<SuperLoggerConfiguration> iterator = serviceLoader.iterator();
        SuperLoggerConfiguration configuration;

        while(iterator.hasNext()) {
            configuration = iterator.next();//加载并初始化实现类
        }
        configuration.configure(configFile);
    }
    
    public static getLogger(Class clazz){
        ......
    }
}

and so on. Why is iterator used here? Instead of getting only one instance method like get?

Imagine that if it is a fixed get method, then the get is a fixed instance. What is the meaning of SPI?

The purpose of SPI is to enhance scalability. Extract the fixed configuration and configure it through the SPI mechanism. That being the case, there is usually a default configuration, and then different implementations are configured through the SPI file, so there will be a problem of multiple implementations of one interface. If multiple implementations are found, which one should be used as the final instance?

So here use iterator to get all implementation class configuration. The default SuperLoggerConfiguration implementation has been added to our super-logger

In order to support YAML configuration, now add a YAMLConfiguration SPI configuration in the user/user code:

META-INF/services/com.github.kongwu.spisamples.SuperLoggerConfiguration:

com.github.kongwu.spisamples.ext.YAMLConfiguration

At this time, through the iterator method, you will get the default XMLConfiguration and the YAMLConfiguration we extended two configuration implementation classes.

In the code loaded above, we traverse the iterator, traversing to the end, we ** use the last implementation configuration as the final instance.

wait? the last one? How to count as the last one?

Is this YAMLConfiguration customized by the user/user necessarily the last one?

This is not necessarily true. It depends on the ClassPath configuration of our runtime. The jar loaded in the front is naturally in the front, and the jar in the last is of course also in the back. Therefore, will be in the last position if the user's package is in the lower order in the ClassPath than the super-logger package; if the user's package is in the first position, then the so-called last one is still the default XMLConfiguration.

For example, if the startup script of our program is:

java -cp super-logger.jar:a.jar:b.jar:main.jar example.Main

The default XMLConfiguration SPI configuration is super-logger.jar , and the extended YAMLConfiguration SPI configuration file is main.jar , so the last element obtained by the iterator must be YAMLConfiguration.

But what if the classpath order is reversed? main.jar is at the front, super-logger.jar is at the back

java -cp main.jar:super-logger.jar:a.jar:b.jar example.Main

In this way, the last element obtained by the iterator becomes the default XMLConfiguration again. It doesn't make much sense for us to use the JDK SPI. The first element obtained by the iterator is still the default XMLConfiguration.

Since this loading order (classpath) is specified by the user, no matter whether we load the first or last one, it may cause the user-defined configuration to not be loaded.

So this is also a disadvantage of the JDK SPI mechanism. It is impossible to confirm which implementation to load, and it is impossible to load a specific implementation. It is a very

Dubbo SPI

Dubbo loads all components through the SPI mechanism. However, Dubbo did not use Java's native SPI mechanism, but enhanced it to better meet its needs. In Dubbo, SPI is a very important module. Based on SPI, we can easily expand Dubbo. If you want to learn Dubbo's source code, you must understand the SPI mechanism. Next, let's first understand the usage of Java SPI and Dubbo SPI, and then analyze the source code of Dubbo SPI.

A new set of SPI mechanism has been implemented in Dubbo, which is more powerful and more complicated. The relevant logic is encapsulated in the ExtensionLoader class, through the ExtensionLoader, we can load the specified implementation class. The configuration file required by Dubbo SPI needs to be placed in the META-INF/dubbo path, and the configuration content is as follows (the following demo comes from dubbo official documentation).

optimusPrime = org.apache.spi.OptimusPrime
bumblebee = org.apache.spi.Bumblebee

Different from the Java SPI implementation class configuration, Dubbo SPI is configured by key-value pairs, so that we can load the specified implementation class on demand. In addition, the @SPI annotation needs to be marked on the interface when in use. Let's demonstrate the usage of Dubbo SPI:

@SPI
public interface Robot {
    void sayHello();
}

public class OptimusPrime implements Robot {
    
    @Override
    public void sayHello() {
        System.out.println("Hello, I am Optimus Prime.");
    }
}

public class Bumblebee implements Robot {

    @Override
    public void sayHello() {
        System.out.println("Hello, I am Bumblebee.");
    }
}


public class DubboSPITest {

    @Test
    public void sayHello() throws Exception {
        ExtensionLoader<Robot> extensionLoader = 
            ExtensionLoader.getExtensionLoader(Robot.class);
        Robot optimusPrime = extensionLoader.getExtension("optimusPrime");
        optimusPrime.sayHello();
        Robot bumblebee = extensionLoader.getExtension("bumblebee");
        bumblebee.sayHello();
    }
}

biggest difference between Dubbo SPI and JDK SPI is that it supports "alias" , which can obtain a fixed extension point through the alias of an extension point. Just like in the above example, I can get the realization aliased as "optimusPrime" among Robot's multiple SPI implementations, and I can also get the realization aliased as "bumblebee", this function is very useful!

Through the value attribute annotated by @SPI, an "alias" can also be implemented by default. For example, in Dubbo, the default is Dubbo private protocol: dubbo protocol-dubbo://
**
Take a look at the interface of the protocol in Dubbo:

@SPI("dubbo")
public interface Protocol {
    ......
}

On the Protocol interface, an @SPI annotation is added, and the value of the annotation is Dubbo. When the implementation is obtained through SPI, the implementation with the alias dubbo in the Protocol SPI configuration will be obtained. The com.alibaba.dubbo.rpc.Protocol file is as follows:

filter=com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper
listener=com.alibaba.dubbo.rpc.protocol.ProtocolListenerWrapper
mock=com.alibaba.dubbo.rpc.support.MockProtocol


dubbo=com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol


injvm=com.alibaba.dubbo.rpc.protocol.injvm.InjvmProtocol
rmi=com.alibaba.dubbo.rpc.protocol.rmi.RmiProtocol
hessian=com.alibaba.dubbo.rpc.protocol.hessian.HessianProtocol
com.alibaba.dubbo.rpc.protocol.http.HttpProtocol
com.alibaba.dubbo.rpc.protocol.webservice.WebServiceProtocol
thrift=com.alibaba.dubbo.rpc.protocol.thrift.ThriftProtocol
memcached=com.alibaba.dubbo.rpc.protocol.memcached.MemcachedProtocol
redis=com.alibaba.dubbo.rpc.protocol.redis.RedisProtocol
rest=com.alibaba.dubbo.rpc.protocol.rest.RestProtocol
registry=com.alibaba.dubbo.registry.integration.RegistryProtocol
qos=com.alibaba.dubbo.qos.protocol.QosProtocolWrapper

Then only through getDefaultExtension, you can get the extension implementation corresponding to the value on the @SPI annotation

Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getDefaultExtension();
//protocol: DubboProtocol

There is also an Adaptive mechanism, although it is very flexible, but... the usage is not very "elegant", so I won't introduce it here.

There is also a "load priority" in Dubbo's SPI. The internal (internal) is loaded first, then the external (external) is loaded, and loaded in order of priority. is repeated, it will be skipped and will not be loaded.

So if you want to rely on the classpath loading order to overwrite the built-in extensions, it is not sensible. The reason is the same as above-the loading order is not rigorous.

Spring SPI

Spring's SPI configuration file is a fixed file- META-INF/spring.factories , which is similar in function to JDK. Each interface can have multiple extension implementations, which is very simple to use:

//获取所有factories文件中配置的LoggingSystemFactory
List<LoggingSystemFactory>> factories = 
    SpringFactoriesLoader.loadFactories(LoggingSystemFactory.class, classLoader);

The following is a configuration of spring.factories in Spring Boot

# Logging Systems
org.springframework.boot.logging.LoggingSystemFactory=\
org.springframework.boot.logging.logback.LogbackLoggingSystem.Factory,\
org.springframework.boot.logging.log4j2.Log4J2LoggingSystem.Factory,\
org.springframework.boot.logging.java.JavaLoggingSystem.Factory

# PropertySource Loaders
org.springframework.boot.env.PropertySourceLoader=\
org.springframework.boot.env.PropertiesPropertySourceLoader,\
org.springframework.boot.env.YamlPropertySourceLoader

# ConfigData Location Resolvers
org.springframework.boot.context.config.ConfigDataLocationResolver=\
org.springframework.boot.context.config.ConfigTreeConfigDataLocationResolver,\
org.springframework.boot.context.config.StandardConfigDataLocationResolver

......

In Spring SPI, all the configuration is placed in a fixed file, which saves the trouble of configuring a lot of files. As for the extended configuration of multiple interfaces, it is better to use one file or a separate file. This is a matter of opinion (I personally like Spring, which is clean and neat).

Although Spring's SPI belongs to spring-framework (core), it is currently mainly used in spring boot...

Like the previous two SPI mechanisms, Spring also supports the existence of multiple spring.factories files in ClassPath. When loading, these spring.factories files will be loaded in the order of classpath and added to an ArrayList. Since there is no alias, there is no concept of de-duplication, and you can add as many as you have.

But because Spring's SPI is mainly used in Spring Boot, the ClassLoader in Spring Boot will load files in the project first, rather than relying on files in the package. So if you define a spring.factories file in your project, then the file in your project will be loaded first, and in the obtained Factories, the implementation class configured in spring.factories in the project will also be ranked first

If we want to extend an interface, we only need to create a META-INF/spring.factories file in your project (spring boot), 16077e47ae6db8 only add the configuration you want, do not copy the Spring Boot spring.factories file completely and then modify
**
For example, if I just want to add a new LoggingSystemFactory implementation, then I only need to create a new META-INF/spring.factories file instead of copying + modifying it completely:

org.springframework.boot.logging.LoggingSystemFactory=\
com.example.log4j2demo.Log4J2LoggingSystem.Factory

Compared

	JDK SPI	DUBBO SPI	Spring SPI
File way	A separate file for each extension point	A separate file for each extension point	All extension points in one file
Get a fixed implementation	Not supported, you can only get all implementations in order	There is the concept of "alias", a fixed implementation of extension points can be obtained by name, and it is convenient to cooperate with Dubbo SPI annotations	Not supported, all implementations can only be obtained in order. But because Spring Boot ClassLoader will load files in user code first, it can ensure that the user-defined spring.factoires file is the first one, and the custom extension can be fixedly obtained by obtaining the first factory.
other	no	Support Dubbo's internal dependency injection, distinguish Dubbo's built-in SPI and external SPI through the directory, and load the internal first to ensure that the internal priority is the highest	no
Document completeness	Articles and information from the three parties are rich enough	Documents & tripartite materials are abundant enough	The document is not rich enough, but because of the lack of functions, it is very simple to use
IDE support	no	no	IDEA perfect support, with grammar hints

Compared with the three SPI mechanisms, the built-in mechanism of JDK is the weakest, but because it is built-in JDK, there are still certain application scenarios, after all, there is no additional dependency; Dubbo has the most abundant functions, but the mechanism is a bit more complicated, and It can only be used with Dubbo and cannot be regarded as an independent module; Spring's functions are similar to those of JDK. The biggest difference is that all extension points are written in a spring.factories file, which is also an improvement, and IDEA perfectly supports syntax prompts. .

Ladies and gentlemen, do you think the three SPI mechanisms of JDK/Dubbo/Spring, which one is better? Welcome to leave a message in the comment area

reference

• Introduction to the Service Provider Interfaces - Oracle
• Dubbo SPI - Apache Dubbo
• Creating Your Own Auto-configuration - Spring

Originality is not easy, unauthorized reprinting is prohibited. If my article is helpful to you, please like/favorite/follow to encourage and support it ❤❤❤❤❤❤