logging

the picture

a newsroom. reporters file stories all day, each marked with how urgent it is (the level). the editor (the logger) spikes everything below today's bar before anyone reads it. what survives goes to the channels (handlers): the website takes everything, the evening news only the big stories. each channel has its own bar, and a story the editor spiked never reaches any of them.

two gates

the level names differ between libraries, the idea doesn't:

here's java.util.logging, which ships in the JDK, with a handler pointed at stdout and a one-line format:

import java.util.logging.*;
 
void main() {
    System.setProperty("java.util.logging.SimpleFormatter.format", "%4$-7s %3$s: %5$s%n");
    Logger log = Logger.getLogger("orders");
    log.setUseParentHandlers(false);                     // don't also print via the root's handler
    Handler out = new StreamHandler(System.out, new SimpleFormatter()) {
        @Override public synchronized void publish(LogRecord r) { super.publish(r); flush(); }
    };
    out.setLevel(Level.ALL);                             // gate 2: this handler takes everything
    log.addHandler(out);
 
    log.setLevel(Level.INFO);                            // gate 1
    log.fine("cart has 3 items");                        // below INFO: dropped
    log.info("order 42 placed");
    log.warning("stock low for sku-7");
 
    log.setLevel(Level.FINE);
    log.fine(() -> "cart has " + 3 + " items");          // the lambda runs only because FINE is on now
}

INFO    orders: order 42 placed
WARNING orders: stock low for sku-7
FINE    orders: cart has 3 items

out of the box (no code at all), JUL reads $JAVA_HOME/conf/logging.properties: the root logger at INFO, one ConsoleHandler at INFO, writing two lines per record to stderr. loggers form a tree by name (orders.checkout is a child of orders), and a logger without its own level or handlers uses its parent's.

who's who

the rule that keeps this sane: libraries log through a facade and never configure anything. applications pick one backend. if your library calls logback directly, every app that uses it inherits logback, whether they wanted it or not.

System.Logger is the JDK's own facade. by default it sends everything to java.util.logging, but a backend can plug in through the System.LoggerFinder service (SLF4J ships a bridge for it), so even the JDK's internal logging ends up in your app's backend.

lazy messages

a log line below the level should cost nothing. the trap is that java evaluates arguments before calling the method, so the message is built even when the logger is about to drop it.

log.debug("cart: " + cart.dump());   // dump() runs, string is built, then dropped

log.debug("cart: {}", cart);                                // SLF4J: toString() only if enabled
log.atDebug().log(() -> "cart: " + cart.dump());            // SLF4J 2 fluent API, a supplier
julLogger.fine(() -> "cart: " + cart.dump());               // java.util.logging

// SLF4J, with the logger at INFO
log.debug("state: {}", dump());   // dump() prints "dump ran" and returns a String

structured logging

a log line like order 42 placed for ada in 31 ms is easy to read and annoying to query. structured logging keeps the values as fields, usually one JSON object per line, so a log store can filter order=42 or chart ms:

{"ts":"2026-10-09T08:02:11Z","level":"INFO","logger":"orders","msg":"order placed","order":42,"user":"ada","ms":31,"requestId":"7f3c"}

in SLF4J 2 that's the fluent API plus a JSON encoder in the backend:

log.atInfo().addKeyValue("order", 42).addKeyValue("ms", 31).log("order placed");

for values that belong to a whole request (a request id, a user), the MDC (mapped diagnostic context) attaches them to every line logged on that thread until you clear it. (with virtual threads and thread pools, clear it in a finally.)