All 15 Class Loading & Bytecode Verification questions
More in Class Loading & Bytecode Verification
What are the phases of class loading (loading, linking, initialization), and what specifically happens during each? What causes a ClassNotFoundException versus a NoClassDefFoundError, and how do you distinguish and diagnose each? How does the Java Platform Module System (JPMS, introduced in Java 9) change class loading and encapsulation compared to the traditional classpath model? What is the purpose of the -Xverify:none (or newer -noverify) JVM flag, and why is disabling bytecode verification generally discouraged? What is hot class reloading/redefinition (via Instrumentation.redefineClasses() or a JVM agent), and what are its practical limitations compared to a full class unload/reload? How would you implement a custom ClassLoader to load classes from a non-standard source, such as loading plugin JARs dynamically at runtime, and what challenges arise with class unloading? What is bytecode verification, and what specific categories of invalid or unsafe bytecode does the JVM's verifier reject before allowing a class to run? How does the same class name loaded by two different ClassLoaders create two genuinely distinct types in the JVM, and what problems does this cause (such as with singletons or ClassCastException)? How would you diagnose and resolve a 'split package' problem when using JPMS, where the same package is defined across two different modules on the module path? How does Class Data Sharing (CDS) and Application Class Data Sharing (AppCDS) improve JVM startup time, and how does it relate to class loading and verification?
Advertisement
Java › Class Loading & Bytecode Verification

How does the ServiceLoader mechanism (java.util.ServiceLoader) provide a standardized way to discover and load implementations at runtime without hardcoding class names, and how does it relate to class loading?

Intermediate

Answer

ServiceLoader implements the Service Provider Interface (SPI) pattern: a service interface is defined, implementations are registered by listing their fully-qualified class name in a META-INF/services/ file named after the interface (or via a `provides...with` declaration in module-info.java under JPMS), and ServiceLoader.load(MyService.class) discovers and instantiates all registered implementations found on the classpath/module path at runtime -- this relies on the underlying class loading mechanism to actually resolve and instantiate each discovered implementation class, providing a clean decoupling between an interface's consumers and its concrete implementations.
// META-INF/services/com.example.PaymentProcessor (file content, one implementation class name per line)
// com.example.impl.StripeProcessor
// com.example.impl.PayPalProcessor

ServiceLoader<PaymentProcessor> loader = ServiceLoader.load(PaymentProcessor.class);
for (PaymentProcessor processor : loader) {
    System.out.println("Found processor: " + processor.getClass().getName());
}
Real-world example The JDBC 4.0+ driver auto-registration mechanism uses ServiceLoader internally to automatically discover and register any JDBC driver JAR present on the classpath, eliminating the need for the older explicit Class.forName() driver-registration call entirely.

Common follow-ups: How does ServiceLoader discovery differ between the classpath and JPMS module path?;What are the performance implications of ServiceLoader scanning for implementations at startup?

Java Platform Module System (JPMS);Design Patterns in Java
All 15 Class Loading & Bytecode Verification questions