Third-party dependencies in a JVM service log through java.util.logging, Apache Commons Logging and Log4j 1.x, yet operations wants a single log stream. How do the SLF4J bridge jars solve this, and what must you avoid when installing them?

## The situation SLF4J unifies logging only for code that calls SLF4J. A dependency compiled against `java.util.logging`, Apache Commons Logging or Log4j 1.x still calls those APIs directly, so its output bypasses your configuration entirely: different format, different destination, different level control, and usually invisible in the aggregated stream. Bridges close that gap without recompiling the dependency. ## How a bridge works A bridge jar re-implements the *legacy API's own classes* — same fully-qualified names, same signatures — with bodies that construct SLF4J loggers and forward the calls. Because the dependency was compiled against those names, the JVM links against the bridge instead and never notices. There are two flavours: **Replacement bridges** (Commons Logging, Log4j 1.x). The original jar must be *removed* from the classpath and the bridge put in its place. Two jars claiming the same class names is a coin-flip resolved by class-loader order, so you exclude the real one in the build. Commons Logging is the historically messy case because its runtime discovery mechanism causes odd behaviour in container class loaders; replacing it with the bridge is also the standard cure for that. **Handler bridges** (`java.util.logging`). You cannot shadow JDK classes, so this bridge instead installs a JUL `Handler` at runtime that receives JUL records and republishes them through SLF4J. Installation is explicit and early: remove the default handlers from the JUL root logger, then install the SLF4J handler, before any dependency has cached a logger reference. Because a JUL record is only offered to handlers after JUL's own level check passes, you must also open JUL's level up (typically to the lowest you want visible) and let the SLF4J backend decide what to keep. That has a cost: JUL now creates a record for events your backend will drop. Logging frameworks that consume this bridge often provide a level-propagation hook so the JUL level tracks the backend's effective level; if not, the pragmatic setting is to open JUL to the lowest level you ever want and accept the extra work. **Log4j2** is symmetric but reversed depending on direction: you can route SLF4J calls into Log4j2 (a binding) or route Log4j2 API calls into SLF4J (a bridge). Choosing the wrong pair is exactly the loop hazard below. ## The loop hazard Every bridge points *toward* SLF4J; every binding points *away* from SLF4J toward an implementation. Put a bridge and its mirror-image binding in the same classpath and events cycle: the legacy call enters SLF4J, the binding routes it back to the same legacy framework, the bridge catches it again, and the process ends in a stack overflow or a hang. The dangerous pairs are a Log4j-1.x-over-SLF4J bridge with an SLF4J-to-Log4j-1.x binding, the JUL bridge with the SLF4J-to-JUL binding, and the two directions of the Log4j2 adapters together. Recent SLF4J versions detect the well-known combinations and fail fast with a message rather than looping, but you should not rely on detection for every combination — model it yourself as a direction check on your dependency tree. ## Operational checklist 1. Choose exactly one backend and one SLF4J provider. 2. For each legacy API present transitively, add its bridge and exclude the original jar. 3. For the JUL bridge, install it programmatically at startup and open the JUL root level. 4. Add a build rule that fails when a banned jar (the original legacy jars, a second provider, an inverse binding) reappears through a transitive upgrade. This is the control that keeps working a year later, because dependency trees change under you. 5. Verify empirically: trigger a log line from a dependency you know uses the legacy API and confirm it appears with your pattern and your MDC fields, not just that the process starts. ## Cost and caveats Bridging adds a small per-event indirection, and the JUL case adds record creation for filtered events. Some level semantics do not map perfectly — JUL has finer-grained levels than SLF4J's five, so several JUL levels collapse onto DEBUG or TRACE, and the original level name is not recoverable downstream. Caller-location data (class, method, line) still works but is computed through an extra frame, which is another reason to avoid layouts that require it on hot paths.