A class that ships inside the JDK — say a factory that discovers implementations through java.util.ServiceLoader — needs to instantiate an implementation class that lives in your application's JAR. Strict parent-first delegation makes that impossible, because the JDK's loader cannot see application classes. How does the platform get around this?

## The directional problem Delegation makes visibility strictly one-way. A loader can see every class its ancestors can define, because it asks them. An ancestor can see nothing its descendants define, because it never asks downward — asking downward would immediately destroy the single-definition guarantee that makes delegation worth having. That is fine until you hit the service-provider pattern, which is deliberately shaped the other way: - The **interface or abstract API** is a shared contract, so it must live high (JDK or container) to keep exactly one definition. - The **implementation** is pluggable and application-specific, so it lives low (application class path or a plugin loader). - And the **code that must instantiate the implementation** is the API's own factory — living high. JDBC, JAXP, JNDI, JCE providers, logging bindings and every `ServiceLoader`-based mechanism have this shape. The high code must construct a low class. Strict parent-first cannot do it. ## The thread context class loader The platform's answer is to attach a loader to the *thread* rather than to the class doing the loading. `java.lang.Thread` carries a context class loader: ```java ClassLoader cl = Thread.currentThread().getContextClassLoader(); Thread.currentThread().setContextClassLoader(cl); ``` Properties worth knowing: - The primordial thread's context loader is initialised to the **system (application) class loader**. - A new thread **inherits** its creator's context loader at construction time. - Any code can set it, so it is a mutable, ambient, thread-local piece of state. JDK code that needs an application-supplied class reads this loader and loads through it. Because that loader is a descendant of the JDK's own, it can see both the shared interface (via delegation upward) and the implementation (locally). Delegation has been inverted *for that specific lookup* while remaining intact everywhere else. ## ServiceLoader specifics `ServiceLoader.load(Service.class)` is documented to use the current thread's context class loader. That is convenient and also the source of most of the surprises, because it depends on ambient state you may not control. `ServiceLoader.load(Service.class, someLoader)` takes the loader explicitly and is preferable whenever you know which loader should provide implementations — typically `Service.class.getClassLoader()` in a plugin-free application, or the plugin's loader in a container. Library authors should expose a loader parameter rather than silently depending on the context loader. In a modular application, `ServiceLoader` also resolves providers declared with `provides ... with ...` in module descriptors, and `ServiceLoader.load(ModuleLayer, Service.class)` searches a specific layer — a cleaner, declarative alternative to the ambient loader for modular deployments. ## Related inversions - **JDBC.** Historically `Class.forName` on a driver name registered it with `DriverManager`; modern drivers are discovered via `ServiceLoader`. `DriverManager` additionally screens candidate drivers by whether the *caller's* loader can see them, which is another form of reaching downward safely. - **Logging facades and JAXP factories** read system properties and then load the named class through the context loader. - **Frameworks generally** — anything that instantiates a class named in configuration must decide *which loader* resolves that name, and the context loader is the usual default. ## Where it goes wrong operationally The context loader is ambient state, so it is only correct if someone set it correctly: - **Thread pools.** A pool thread keeps the context loader of whichever thread created it, forever. If a container created the pool during startup, tasks submitted later from a plugin still run with the container's loader and cannot see plugin classes. Symptom: `ClassNotFoundException` or `ServiceConfigurationError` for a class that is demonstrably on the plugin's class path, and which works when invoked on the request thread. - **Containers.** Servlet containers set the context loader to the web application's loader before invoking application code and restore it afterwards. Anything running outside that window — a background timer, an asynchronous callback — does not get that treatment. - **Leaks.** Holding a reference to a web application's loader in a long-lived thread's context field keeps the entire application's classes reachable after undeploy. ## The discipline ```java Thread t = Thread.currentThread(); ClassLoader saved = t.getContextClassLoader(); try { t.setContextClassLoader(pluginLoader); ServiceLoader.load(Codec.class).forEach(this::register); } finally { t.setContextClassLoader(saved); // always restore } ``` Set it narrowly around the call, always restore in `finally`, and prefer passing the loader explicitly when the API allows. Treat a context-loader dependency in a library as something to document loudly, because it makes the library's behaviour depend on invisible state. ## Interview framing "Delegation is one-way, so a parent-loaded factory can't see a child-loaded implementation. The platform inverts it deliberately through the thread context class loader — `ServiceLoader.load(Service.class)` uses it by default, and the two-arg overload lets you pass a loader explicitly, which I prefer. The failure mode to watch is a pooled thread carrying a stale context loader, which produces ClassNotFoundException for classes that are obviously present."