Java SPI: From Parent Delegation to Dubbo Enhancements – What Interviewers Expect

Problem SPI solves

Hard‑coding concrete implementations forces source changes and recompilation when swapping components such as JDBC drivers or logging libraries. SPI (Service Provider Interface) lets a framework depend only on an interface while third‑party JARs place a configuration file in META-INF/services/ that lists implementation class names. At runtime ServiceLoader discovers the implementations.

Typical JDBC example: before JDBC 4.0 the application called Class.forName("com.mysql.jdbc.Driver"). Since JDBC 4.0 the driver registers itself in META-INF/services/java.sql.Driver and DriverManager loads it via ServiceLoader.load(Driver.class), shifting control from the application to the framework.

Interface : the extension contract defined by the framework (public interface).

Configuration file : META-INF/services/<full‑interface‑name>, UTF‑8, one implementation per line.

Implementation class : the provider class, must have a public no‑arg constructor and be loadable by the current class loader.

Thread Context Class Loader (TCCL) and SPI loading

The bootstrap class loader cannot see classes loaded by the application class loader due to the parent‑delegation model. The no‑arg overload of ServiceLoader.load uses the current thread’s context class loader (TCCL), which defaults to the application class loader and can scan the application classpath.

public static <S> ServiceLoader<S> load(Class<S> service) {
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    return new ServiceLoader<>(Reflection.getCallerClass(), service, cl);
}

DriverManager.getConnection

also falls back to TCCL when the caller’s class loader is null or the platform loader.

Thus SPI uses TCCL to bypass the parent‑delegation restriction, allowing framework code in rt.jar to load implementations that reside in the application classpath.

How JDK SPI works

Roles of framework and provider

The framework (consumer) depends only on the interface, e.g., java.sql.Driver. The provider places two items in its JAR: the implementation class and a file META-INF/services/java.sql.Driver listing the fully‑qualified class name. Multiple drivers can register themselves without changing framework code.

Loading order

Calling ServiceLoader.load(Driver.class) creates a loader but does not instantiate drivers. The actual scanning of META-INF/services/java.sql.Driver happens when the iterator’s next() method is invoked, which is a lazy‑loading behavior.

ServiceLoader<Driver> loader = ServiceLoader.load(Driver.class);
Iterator<Driver> it = loader.iterator();
Driver driver = it.next(); // classpath is scanned here

If several driver JARs are present, their configuration files are merged, and the iterator yields each driver in order. DriverManager.getConnection(url) then asks each driver whether it can handle the URL, selecting the first suitable one. The SPI only discovers implementations; the framework decides which one to use.

SPI in Kafka Connect and Elasticsearch

Both projects use the standard META-INF/services/ convention but differ in class‑loader handling and instantiation timing.

Kafka Connect : treats plugin JARs under plugin.path as a plugin library. At startup, ServiceLoaderScanner scans these JARs, verifies that classes are loadable, public, and have a no‑arg constructor before adding them to the usable list. It follows the standard ServiceLoader rules.

Elasticsearch : uses a custom SPIClassIterator that reads the services file but delays actual class instantiation. Each plugin gets its own class loader, avoiding class‑path order and static‑initialization problems that could break startup.

Dubbo’s enhanced SPI

Dubbo extends the JDK SPI because RPC frameworks need named lookup, priority, conditional activation, and decorator chains. It stores configuration in META-INF/dubbo/internal/<interface> with lines like dubbo=org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol. Loading is performed by name via

ExtensionLoader.getExtensionLoader(Protocol.class).getExtension("dubbo")

.

Get by name : getExtension("dubbo") retrieves a specific implementation without full iteration.

@Adaptive : selects an implementation at runtime based on URL parameters.

@Activate : provides conditional activation and ordering.

Wrapper : implements a decorator chain around extension points.

Dubbo does not replace the JDK SPI spec; it builds on it to provide discovery, selection, and assembly for RPC extensions.

Why Spring Boot does not use JDK SPI

Spring Boot’s auto‑configuration is driven by files under META-INF/spring/ with the pattern *.imports, loaded by SpringFactoriesLoader. This mechanism is separate from JDK SPI and works together with @Conditional annotations for conditional bean registration.

Configuration file : JDK SPI uses META-INF/services/<interface>; Spring Boot uses META-INF/spring/*.imports.

Format : one implementation class name per line in both cases.

Typical use : JDK SPI for JDBC and plugin discovery; Spring Boot for starter auto‑configuration.

Evaluation of Java SPI

SPI remains suitable when the interface is stable, implementations are packaged in independent JARs, and the framework is willing to perform its own selection logic. Typical use cases include JDBC drivers, Elasticsearch plugins, and Kafka Connect connectors.

Cannot retrieve an implementation directly by name; only iteration is provided.

Lacks built‑in priority and conditional activation; frameworks must implement their own rules when multiple implementations coexist.

Only creates new objects; it does not perform dependency injection, so providers must manage their own dependencies.