Master Java SPI: From JDK to Dubbo & Spring – Extend Your Apps Easily

SPI (Service Provider Interface) is a service discovery mechanism that registers fully qualified class names in configuration files, allowing dynamic replacement of implementations at runtime.

Example: a simple logging framework "super‑logger" defines an interface SuperLoggerConfiguration and a default XML implementation XMLConfiguration. Initially, LoggerFactory directly creates XMLConfiguration, which limits extensibility.

By placing a file

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

containing the implementation class name, Java’s ServiceLoader can load all implementations. The code to load them looks like:

ServiceLoader<SuperLoggerConfiguration> serviceLoader = ServiceLoader.load(SuperLoggerConfiguration.class);
Iterator<SuperLoggerConfiguration> iterator = serviceLoader.iterator();
SuperLoggerConfiguration configuration;
while (iterator.hasNext()) {
    // load and initialize implementation
    configuration = iterator.next();
}
configuration.configure(configFile);

The LoggerFactory static block is rewritten to use this SPI loading, enabling users to add a YAMLConfiguration implementation without modifying the factory code.

However, JDK SPI selects implementations based on class‑path order; the last loaded implementation is used, which can be unpredictable.

Dubbo SPI

Dubbo enhances SPI by using key‑value pairs in META-INF/dubbo files, allowing each implementation to have an alias. Interfaces are annotated with @SPI, and implementations can be retrieved by name via ExtensionLoader:

@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."); }
}
ExtensionLoader<Robot> loader = ExtensionLoader.getExtensionLoader(Robot.class);
Robot optimus = loader.getExtension("optimusPrime");
optimus.sayHello();
Robot bumble = loader.getExtension("bumblebee");
bumble.sayHello();

Dubbo also supports a default implementation via the value attribute of @SPI, and an adaptive mechanism for more flexible loading.

Spring SPI

Spring uses a single file META-INF/spring.factories where each interface maps to a comma‑separated list of implementation classes. For example, loading all LoggingSystemFactory implementations:

List<LoggingSystemFactory> factories = SpringFactoriesLoader.loadFactories(
    LoggingSystemFactory.class, classLoader);

Typical content of spring.factories includes entries for logging systems, property source loaders, and other boot components. Adding a custom implementation only requires adding a new line for the desired interface, without copying the entire file.

Spring’s SPI loads files in class‑path order, giving priority to user‑defined factories, which makes it easy to override default behavior.

Comparison

JDK SPI uses separate files per extension point, provides only ordered loading, and has no alias support. Dubbo SPI adds aliasing, internal vs external priority, and richer documentation. Spring SPI consolidates all extensions into one file, relies on class‑path order, and enjoys IDE support.

Overall, JDK SPI is the simplest but least flexible, Dubbo SPI offers the most features but is tied to Dubbo, and Spring SPI strikes a balance with straightforward configuration and good tooling.