Mastering Java Logging: Understanding Frameworks, Dependencies, and Best Practices

Overview

The purpose of this article is to clarify the relationships among various Java logging libraries, how they work and depend on each other, so that developers can troubleshoot issues such as missing logs or jar conflicts and configure unified logging across frameworks.

Log Framework History

In daily work we encounter many logging jars such as commons-logging.jar, log4j.jar, slf4j-api.jar, logback.jar, etc. To configure them correctly we first need to understand their evolution.

Background / Development History

log4j, created by Ceki Gülcü, became the de facto standard for Java logging.

Apache proposed integrating log4j into the JDK, but Sun rejected it; JDK 1.4 introduced java.util.logging (JUL).

JUL is bundled with the JDK and widely used, alongside other simple loggers. Switching from log4j to JUL requires code changes because the APIs differ.

Apache responded by creating Jakarta Commons Logging (JCL), a thin abstraction that does not provide an implementation, allowing runtime selection of the actual logging backend.

log4j’s author found JCL cumbersome and created SLF4J, another façade that also does not provide an implementation, aiming to replace JCL, and later developed Logback as a high‑performance implementation to replace log4j.

Apache, inspired by Logback, released log4j2 with many optimizations.

Relationships / Dependencies

After understanding the history, we examine how the libraries depend on each other.

JCL

commons-logging

is no longer maintained. It provides only an API and relies on an underlying implementation such as Log4j or JUL. Its usage has declined, especially in modern Spring projects.

SLF4J

SLF4J was created to provide a uniform façade for the chaotic Java logging ecosystem. It offers adapters for most popular logging implementations. Typical dependency combinations are:

slf4j + logback: slf4j-api.jar + logback-classic.jar + logback-core.jar slf4j + log4j: slf4j-api.jar + slf4j-log4j12.jar + log4j.jar slf4j + JUL: slf4j-api.jar + slf4j-jdk14.jar slf4j without an implementation: slf4j-api.jar +

slf4j-nop.jar

SLF4J Adapter

SLF4J supports various adapters, allowing any existing logging implementation to be used through the SLF4J façade. The diagram from the official documentation illustrates this relationship.

Spring Integration

Spring uses JCL as its logging façade. To make Spring log through SLF4J + Logback, simply add jcl-over-slf4j.jar to the classpath. The following diagram shows the resulting unified logging flow.

Adaptation Approach

Identify the logging framework used by the target module or library and select the appropriate SLF4J adapter.

Remove unnecessary logging implementations, keeping only the desired one.

Common Issues

SLF4J reports the chosen logging implementation at startup. Typical problems include:

Failed to load class org.slf4j.impl.StaticLoggerBinder

No logging implementation found; often caused by missing or incompatible jars.

Multiple bindings

More than one logging implementation is present; SLF4J will pick one arbitrarily.

Code Standards

According to Alibaba’s coding guidelines, applications should depend only on the SLF4J API and avoid direct use of Log4j or Logback APIs. Example: <code>import org.slf4j.Logger; import org.slf4j.LoggerFactory; private static final Logger logger = LoggerFactory.getLogger(MyClass.class); </code>

Conclusion

This article organizes the relationships among Java logging components and provides practical solutions for common logging problems, helping developers achieve consistent and maintainable log output.