Use SLF4J for logging abstraction to decouple code from implementation. 2. Choose Logback for simplicity and Spring Boot compatibility or Log4j 2 for high performance and advanced features. 3. Avoid JUL and Log4j 1.x except in legacy systems. 4. Route JUL logs to SLF4J using jul-to-slf4j when needed. 5. Always log exceptions with the exception object, use parameterized messages, avoid sensitive data, enable structured logging, and test configurations—this ensures maintainable, debuggable, and secure logging in production.

Java logging is one of those things every developer uses but often doesn’t think deeply about—until something goes wrong in production. Choosing the right logging framework (or understanding how the ones you’re already using work together) can save you hours of debugging and make your application more maintainable.

Let’s break down the Java logging landscape in a practical, developer-friendly way—no marketing fluff, just what you need to know to make good decisions.

1. The Core: java.util.logging (JUL)

Built-in, but often overlooked

Java comes with its own logging framework: java.util.logging, or JUL for short. It's part of the standard library, so you don't need any external dependencies.

import java.util.logging.Logger;

public class MyApp {
    private static final Logger logger = Logger.getLogger(MyApp.class.getName());

    public void doSomething() {
        logger.info("Something happened");
    }
}

Pros:

• No extra dependencies
• Simple for basic use
• Works out of the box

Cons:

• Limited features compared to others
• Verbose configuration
• Poor performance under high load
• Not widely used in modern frameworks

When to use it: Small apps, learning, or environments where you can't add dependencies. Otherwise, most teams opt for something more powerful.

2. The Old Guard: Log4j 1.x

Once dominant, now deprecated

Log4j was the go-to logging framework in the early 2000s. It offered flexibility, performance, and configurability via XML or properties files.

But Log4j 1.x is deprecated. Don’t use it in new projects. It’s unmaintained, has known performance issues, and lacks modern features.

3. The Popular Choice: Log4j 2

Modern, fast, and feature-rich

Log4j 2 is a complete rewrite of Log4j 1.x and is actively maintained by Apache. It fixes the architectural flaws of its predecessor and adds great features.

<!-- log4j2.xml -->
<Configuration>
  <Appenders>
    <Console name="Console" target="SYSTEM_OUT">
      <PatternLayout pattern="%d{HH:mm:ss} [%t] %-5level %logger{36} - %msg%n"/>
    </Console>
  </Appenders>
  <Loggers>
    <Root level="info">
      <AppenderRef ref="Console"/>
    </Root>
  </Logers>
</Configuration>

Pros:

• Excellent performance (especially with async loggers)
• Modular architecture
• Supports JSON, custom levels, plugins
• Integrates well with modern tools (Kafka, AWS, etc.)

Cons:

• Suffers from the shadow of the 2021 Log4Shell vulnerability (CVE-2021-44228), though it's been fixed and patched
• Slightly heavier than some alternatives

Use case: High-performance applications, microservices, or when you need advanced logging features.

4. The Elegant Alternative: Logback

The spiritual successor to Log4j 1.x

Developed by Ceki Gülcü (the original author of Log4j), Logback was designed to be faster and more flexible than its predecessor. It’s the native implementation of SLF4J (more on that soon).

<!-- logback.xml -->
<configuration>
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>%d{HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n</pattern>
    </encoder>
  </appender>

  <root level="info">
    <appender-ref ref="STDOUT" />
  </root>
</configuration>

Pros:

• Fast and reliable
• Great documentation
• Built-in support for auto-reloading config files
• Seamless integration with SLF4J

Cons:

• No built-in support for JSON formatting (requires extra libraries)
• Development has slowed a bit compared to Log4j 2

Use case: Spring Boot apps (which use Logback by default), or when you want a clean, mature setup.

5. The Abstraction Layer: SLF4J (Simple Logging Facade for Java)

Not a logging framework—it’s a facade

SLF4J isn’t a logger itself. It’s a logging abstraction that lets you write logging code without tying it to a specific backend.

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

public class MyService {
    private static final Logger logger = LoggerFactory.getLogger(MyService.class);

    public void process() {
        logger.info("Processing item: {}", itemId);
    }
}

Why it matters:

• Decouples your code from the actual logging framework
• You can switch from Logback to Log4j 2 (or JUL) just by changing dependencies
• Provides clean, parameterized logging (no string concatenation in hot paths)

How it works:

• You code against SLF4J APIs
• At runtime, SLF4J binds to a real implementation (Logback, Log4j 2, JUL, etc.)
• Use slf4j-api one binding (e.g., logback-classic or log4j-slf4j-impl)

Pro tip: Always depend on slf4j-api, never on a concrete logging framework directly in libraries.

6. The New Kid: java.util.logging SLF4J? Or JUL gone?

Wait—what about JUL and SLF4J?

You can route JUL logs into SLF4J using jul-to-slf4j bridge. This lets you centralize all logging (even from legacy code or libraries using JUL) into your main logging pipeline.

// At app startup
SLF4JBridgeHandler.install();

Now java.util.logging.Logger messages go through SLF4J and appear in your Logback/Log4j 2 output.

7. Best Practices for Real-World Apps

Here’s what works in production:

• ? Use SLF4J in your code — always
• ? Pick one backend: Logback (simpler) or Log4j 2 (faster, more features)
• ? Avoid logging sensitive data — mask passwords, tokens, PII
• ? Use structured logging when possible — consider Logstash or JSON layouts
• ? Don’t concatenate strings in log statements — use placeholders

logger.debug("User {} logged in from {}", user.getId(), ip); // Good
logger.debug("User "   user.getId()   " logged in");         // Bad — always evaluates string

• ? Control log levels per package — e.g., debug for your app, warn for third-party libs
• ? Test your logging config — make sure it works in staging

Final Thoughts

You don’t need to overthink logging—but you should get it right early.

For most new projects:

• Use SLF4J Logback if you want simplicity and solid defaults (especially with Spring Boot)
• Use SLF4J Log4j 2 if you need maximum performance or advanced features

Avoid JUL and Log4j 1.x unless you’re maintaining legacy code.

And no matter what—never log exceptions like this:

} catch (Exception e) {
    logger.error("Something broke");
}

Always include the exception:

} catch (Exception e) {
    logger.error("Something broke", e);
}

Basically, that’s it. Solid logging isn’t flashy, but it’s one of the best things you can do for your future self.

The above is the detailed content of A Developer's Guide to Java Logging Frameworks. For more information, please follow other related articles on the PHP Chinese website!