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.
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.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
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
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
