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

This article explains the evolution and inter‑relationships of Java logging libraries such as Log4j, JUL, JCL, SLF4J and Logback, shows how to configure adapters to unify logging across frameworks, addresses common runtime issues, and provides coding‑style recommendations for consistent log output.

Code Ape Tech Column
Code Ape Tech Column
Code Ape Tech Column
Understanding Java Logging Frameworks: Relationships, Dependencies, and Best Practices

The purpose of this article is to clarify how various Java logging libraries relate to each other, how they work, and their dependencies, so that developers can troubleshoot problems like missing logs or jar conflicts and achieve unified log output across different frameworks.

Background and History

Java logging started with Log4j, which became the de‑facto standard. Apache later introduced JUL (java.util.logging) in JDK 1.4, while other components such as SimpleLog also appeared. To avoid hard‑coding a specific implementation, Apache created Jakarta Commons Logging (JCL) as an abstraction layer, and later the author of Log4j developed SLF4J as a similar façade, eventually leading to Logback and Log4j2.

Relationships and Dependencies

JCL provides a generic API without an implementation, allowing runtime selection of the actual logging engine. SLF4J serves the same purpose but is more widely adopted, and it offers adapters for various implementations:

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 Adapters such as jcl-over-slf4j.jar, log4j-over-slf4j.jar, and jul-to-slf4j.jar enable existing code that uses JCL, Log4j, or JUL to route logging through SLF4J.

Spring Integration Example

Spring uses JCL as its logging façade. To make Spring log through Logback via SLF4J, simply add jcl-over-slf4j.jar to the classpath and remove other logging implementations, achieving consistent log formatting, file locations, and other SLF4J features across the whole application.

Common Issues

Failed to load class org.slf4j.impl.StaticLoggerBinder : No logging implementation found, often due to missing or incompatible jars.

Multiple bindings : More than one SLF4J binding is present; SLF4J will pick one, which may cause unexpected behavior.

Code Style Recommendation

According to Alibaba’s coding guidelines, applications should not use the native APIs of Log4j or Logback directly. Instead, they must depend on SLF4J’s API and obtain loggers via:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
private static final Logger logger = LoggerFactory.getLogger(Abc.class);

Conclusion

The article provides a comprehensive overview of Java logging components, their historical development, how they depend on each other, practical steps to resolve typical logging problems, and best‑practice recommendations for achieving unified and maintainable log output in Java backend projects.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

BackendJavalogginglogbacklog4jslf4j
Code Ape Tech Column
Written by

Code Ape Tech Column

Former Ant Group P8 engineer, pure technologist, sharing full‑stack Java, job interview and career advice through a column. Site: java-family.cn

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.