How does a thread context ClassLoader (Thread.currentThread().getContextClassLoader()) solve the problem of a core JDK class needing to load an application-provided implementation class, given parent delegation normally prevents this?

Since parent delegation means the bootstrap/platform loaders can't normally see or load application-level classes (they only delegate upward, never downward), a mechanism was needed for JDK-provided SPI frameworks (like JAXP or JDBC) running on a bootstrap-loaded thread to still locate application-provided implementation classes -- the thread context ClassLoader is a per-thread reference (defaulting to the application ClassLoader) that such JDK code explicitly consults instead of relying purely on the calling code's own class loader, effectively working around the strict upward-only delegation model for this specific, well-defined use case.

// Simplified illustration of how JDK SPI code uses the context ClassLoader
public class SomeJdkSpiLoader {
    public Object loadImplementation(String className) throws Exception {
        ClassLoader ccl = Thread.currentThread().getContextClassLoader();
        Class<?> implClass = ccl.loadClass(className);  // uses context loader, not the bootstrap loader
        return implClass.getDeclaredConstructor().newInstance();
    }
}