Overview of Common Java Logging Frameworks and Their Usage

Java Logging Overview

Logging is an essential part of any application for troubleshooting, business analytics, and monitoring. In the Java ecosystem, several logging frameworks are widely used, including Log4j, Log4j2, Commons Logging, SLF4J, Logback, and Java Util Logging (JUL).

Common Java Logging Frameworks

Log4j : An Apache project originally created by Ceki Gülcü, one of the earliest Java logging tools.

Log4j 2 : The successor to Log4j 1.x, offering improved performance and features.

Commons Logging : A thin logging façade originally known as Jakarta Commons Logging.

SLF4J : A simple façade that delegates to an underlying logging implementation (Simple Logging Facade for Java).

Logback : A native implementation of the SLF4J API, created by the same author.

JUL (Java Util Logging): The official logging API bundled with the JDK since version 1.4.

These frameworks can appear confusing; the following sections clarify their histories and relationships.

History of Java Logging Frameworks

1996: The early European Secure Electronic Market project created a tracing API that evolved into Log4j, later becoming an Apache project.

Early 2000s: Log4j became the de‑facto standard; Sun declined to adopt it into the JDK.

2002: Sun released JUL, which mimicked Log4j’s design.

Mid‑2000s: Apache introduced Commons Logging as a façade, allowing runtime selection of the underlying logger.

2006: Ceki Gülcü left Apache and founded SLF4J and Logback, providing a modern façade and implementation.

Today: The ecosystem is split mainly between the Commons Logging (Apache) camp and the SLF4J/Logback camp.

Relationships Between Frameworks

Log4j2 is not backward compatible with Log4j1.

Commons Logging and SLF4J are façades; Log4j and Logback are concrete implementations.

Typical combinations: SLF4J + Logback or Commons Logging + Log4j.

Logback is designed to work directly with SLF4J, ensuring seamless compatibility.

Implementation Mechanisms Comparison

Commons Logging

Uses a dynamic discovery mechanism at runtime, loading the concrete logger via its own ClassLoader. This can cause issues in OSGi environments where each bundle has an independent ClassLoader.

SLF4J

Performs static binding at compile time by locating org.slf4j.impl.StaticLoggerBinder on the classpath, which makes it OSGi‑friendly.

Choosing a Logging Framework for a New Project

For new projects, the recommended stack is SLF4J combined with Logback, offering several advantages:

SLF4J’s static binding provides broader compatibility and fewer runtime constraints.

Logback delivers superior performance; key operations are measured in nanoseconds compared to Log4j’s higher latency.

SLF4J reduces logging overhead by using parameterized messages, e.g.,

log.debug("User name: {} , buy goods id: {}", user.getName(), good.getId());

, avoiding expensive string concatenation when the log level is disabled.

Logback documentation is fully free, unlike some commercial Log4j resources.

How to Use SLF4J in a Project

SLF4J Bridge JARs for Various Logging Implementations

JAR Name

Description

slf4j-log4j12-1.7.13.jar

Bridge for Log4j 1.2; requires log4j.jar on the classpath.

slf4j-jdk14-1.7.13.jar

Bridge for java.util.logging (JDK’s native logging).

slf4j-nop-1.7.13.jar

No‑operation bridge that discards all log messages.

slf4j-simple-1.7.13.jar

Simple implementation that prints messages to System.err (INFO and higher).

slf4j-jcl-1.7.13.jar

Bridge that routes Commons Logging calls to SLF4J.

logback-classic-1.0.13.jar (requires logback-core-1.0.13.jar)

Native SLF4J implementation; Logback directly implements the SLF4J API.

See the diagram below for a typical integration flow.

Bridging Legacy APIs

In real‑world projects, different libraries may use different logging APIs (e.g., Spring uses Commons Logging, XSocket uses JUL). To unify logging, redirect all logs to SLF4J using the appropriate bridge JARs.

JAR Name

Purpose

log4j-over-slf4j-version.jar

Redirects Log4j calls to SLF4J.

jcl-over-slf4j-version.jar

Redirects Commons Logging calls to SLF4J.

jul-to-slf4j-version.jar

Redirects JUL calls to SLF4J.

Diagram of the bridging process:

Important Notes When Using SLF4J Bridges

Avoid circular dependencies that can cause infinite loops. Do not include the following conflicting pairs in the same classpath:

Conflicting JAR Pair

Cause of Loop

log4j-over-slf4j.jar and slf4j-log4j12.jar

Both redirect each other’s calls, creating a loop.

jul-to-slf4j.jar and slf4j-jdk14.jar

Each forwards logging to the other, resulting in a loop.

Source: cnblogs.com/chenhongliang/p/5312517.html

Java Group – Focused on sharing Java technical content.

Scan the QR code above for more Java resources.