When to use java.util.logging and when to choose another backend

java.util.logging (JUL) is a reasonable choice when a JDK-provided logging system meets your needs. Logback and Log4j 2 offer additional configuration and logging features that can make them more convenient for larger applications. The decision should follow those requirements, not a blanket claim that JUL is slow or unsuitable for every new project.

Where JUL can require more work

Configuration. JUL uses handlers and formatters, commonly configured through a properties file. It supports programmatic configuration and runtime level changes. Logback and Log4j 2 provide different configuration models that may make complex routing easier to express; XML syntax alone does not make one configuration objectively clearer.

Features. JUL includes file rotation through FileHandler, but it does not provide the same ready-made combination of time-and-size rolling, compression, asynchronous appenders, and MDC-style context support found in other backends. Custom handlers and integrations can fill gaps at the cost of additional maintenance.

Performance. Slow output, formatting, and synchronization can all matter. An asynchronous logger can reduce time spent in the calling thread, but it introduces queues, saturation policies, and shutdown behavior. Benchmark the actual workload and destination rather than assuming Logback or Log4j 2 is always faster.

Integration. Many Java applications already use SLF4J with a third-party backend, making shared configuration convenient. JUL remains useful for dependencies and tools that avoid adding a logging library. Check the integrations you need rather than relying on broad ecosystem rankings.

A common application architecture

Application code -> SLF4J API -> Logback or Log4j 2
Dependency JUL calls -> jul-to-slf4j bridge -> the same SLF4J provider

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Service {
    private static final Logger log = LoggerFactory.getLogger(Service.class);

    public void run() {
        log.info("Processing order orderId={}", 1001);
    }
}

Programming against a facade can keep basic logging call sites stable when switching backends. Dependencies, configuration, extensions, and provider compatibility still need adjustment.

Adding jul-to-slf4j to the classpath is not sufficient by itself. In an application that owns the logging setup, install its bridge once at startup, before normal logging begins:

import org.slf4j.bridge.SLF4JBridgeHandler;

SLF4JBridgeHandler.removeHandlersForRootLogger();
SLF4JBridgeHandler.install();

The removal call prevents the usual root console handler from duplicating bridged events. Review existing JUL handler ownership before removing handlers in an embedded or managed environment. Configure JUL levels as well: an event filtered out by JUL cannot be recovered downstream. Do not combine this bridge with an SLF4J provider that routes back to JUL, such as slf4j-jdk14, because that creates a loop.

Emit one event through JUL and one through SLF4J, then verify that each reaches the intended destination exactly once. If DataKit collects the resulting file, also check logger names, levels, and exception stacks after parsing.

Frequently asked questions

Must I rewrite an existing JUL application?

No. A properly installed bridge can route existing calls to SLF4J. Test filtering, duplicate handlers, and overhead before migrating; keeping JUL is also valid when it meets the application's requirements.

What does Spring Boot use by default?

With the usual logging starter, Spring Boot uses Logback through SLF4J. A different dependency set can select another backend. That default does not make JUL inherently incorrect.

Where does JUL fit well?

Small utilities, libraries, and environments that favor JDK-provided facilities can use it without adding a third-party logging backend. Choose a richer backend when its features solve a concrete operational need.

See the JUL LogManager API and SLF4JBridgeHandler.