A classification, log frame
- Facade type logging framework:
- jakartaCommonsLoggingImpl (JCL).
- Simple Logging Facade for Java (SLF4J)。
- Record type logging framework:
- JUL: Logging tool in the JDK, often referred JDKLog, jdk-logging.
- Log4j: logging a specific implementation framework.
- Log4j2: a specific log implementation framework, it is the next version of LOG4J1.
- Logback: logging a specific implementation framework, but better performance.
Second, the development process
To figure out their relationship, we must start with they are produced under what circumstances. We follow the chronological order to introduce.
Laog4j
In JDK 1.3 and earlier, Java hit the log rely System.out.println (), System.err.println () or e.printStackTrace (), Debug logs are written to STDOUT stream, the error log is written to STDERR stream. Log this fight has a very large defects that can not be customized, and the log size is not detailed enough.
So, Gülcü Log4j released in 2001, and later became the Apache Foundation top-level project. Log4j in the design is very good, there are long-term and far-reaching influence on the subsequent frame of Java Log, Logger, Appender, Level concepts such as its definitions has now been widely used. Log4j short board performance that, after Logback and Log4j2 out, using Log4j also reduced.
J.U.L
Inspired by Logj, Sun introduced Java1.4 version of java.util.logging, log4j but jul so much as complete, developers need to write your own Appenders (Sun called Handlers), and only two Handlers available (Console and File), jul after Java1.5 performance and availability have been enhanced.
JCL (commons-logging)
Since the log print two inevitable choice of projects in the framework of at least one, at this time, Apache's JCL (commons-logging) was born. JCL is a Log Facade, only provides Log API, does not provide an implementation, then there Adapter Log4j or JUL used as Log Implementation.
Log is created and recorded in the program are using the JCL interface, in real operation, we will look at what is currently in ClassPath be achieved if there is to use Log4j Log4j, if not consequently is to use the JDK JUL.
In this way, in your project, as well as third-party projects, we use the JCL logging interface, then eventually when running the program, according to their own needs (or preferences) to select the appropriate use of Log Implementation. If you use Log4j, Log4j jar package is added in, and then write a Log4j configuration file; if JUL like to use, you just need to write a configuration file JUL. If there are other new log library appears, it only needs to provide a Adapter, this time running log database jar package added.
However, commons-logging and Log4j configuration issues jul compatibility is not good, use commons-loggings may also encounter class loading problems, leading NoClassDefFoundError error.
By this time all looks very simple, very good. Interface and implementation to do a good separation, under the unified JCL, without changing any code, you can configure it by switching to a more powerful, better performance or logging library implementation.
This simple beautiful SLF4J continued to appear.
SLF4J & Logback
SLF4J（Simple Logging Facade for Java）和 Logback 也是Gülcü 创立的项目，目的是为了提供更高性能的实现。
从设计模式的角度说，SLF4J 是用来在log和代码层之间起到门面作用，类似于 JCL 的 Log Facade。对于用户来说只要使用SLF4J提供的接口，即可隐藏日志的具体实现，SLF4J提供的核心API是一些接口和一个LoggerFactory的工厂类，用户只需按照它提供的统一纪录日志接口，最终日志的格式、纪录级别、输出方式等可通过具体日志系统的配置来实现，因此可以灵活的切换日志系统。
Logback是log4j的升级版，当前分为三个目标模块：
- logback-core：核心模块，是其它两个模块的基础模块
- logback-classic：是log4j的一个改良版本，同时完整实现 SLF4J API 使你可以很方便地更换成其它日记系统如log4j 或 JDK14 Logging
- logback-access：访问模块与Servlet容器集成提供通过Http来访问日记的功能，是logback不可或缺的组成部分
Logback相较于log4j有更多的优点：
- 更快的执行速度
- 更充分的测试
- logback-classic 非常自然的实现了SLF4J
- 使用XML配置文件或者Groovy
- 自动重新载入配置文件
- 优雅地从I/O错误中恢复
- 自动清除旧的日志归档文件
- 自动压缩归档日志文件
- 谨慎模式
- Lilith
- 配置文件中的条件处理
- 更丰富的过滤
更详细的解释参见官网：https://logback.qos.ch/reasonsToSwitch.html
到这里，你可能会问：Apache 已经有了个JCL，用来做各种Log lib统一的接口，如果 Gülcü 要搞一个更好的 Log 实现的话，直接写一个实现就好了，为啥还要搞一个和SLF4J呢?
原因是Gülcü 认为 JCL 的 API 设计得不好，容易让使用者写出性能有问题的代码。关于这点，你可以参考这篇文章获得更详细的介绍：https://zhuanlan.zhihu.com/p/24272450
现在事情就变复杂了。我们有了两个流行的 Log Facade，以及三个流行的 Log Implementation。Gülcü 是个追求完美的人，他决定让这些Log之间都能够方便的互相替换，所以做了各种 Adapter 和 Bridge 来连接:
可以看到甚至 Log4j 和 JUL 都可以桥接到SLF4J，再通过 SLF4J 适配到到 Logback！需要注意的是不能有循环的桥接，比如下面这些依赖就不能同时存在:
- jcl-over-slf4j 和 slf4j-jcl
- log4j-over-slf4j 和 slf4j-log4j12
- jul-to-slf4j 和 slf4j-jdk14
然而，事情在变得更麻烦！
Log4j2
现在有了更好的 SLF4J 和 Logback，慢慢取代JCL 和 Log4j ，事情到这里总该大统一圆满结束了吧。然而维护 Log4j 的人不这样想，他们不想坐视用户一点点被 SLF4J / Logback 蚕食，继而搞出了 Log4j2。
Log4j2 和 Log4j1.x 并不兼容，设计上很大程度上模仿了 SLF4J/Logback，性能上也获得了很大的提升。Log4j2 也做了 Facade/Implementation 分离的设计，分成了 log4j-api 和 log4j-core。
现在好了，我们有了三个流行的Log 接口和四个流行的Log实现，如果画出桥接关系的图来回事什么样子呢?
看到这里是不是感觉有点晕呢？是的，我也有这种感觉。同样，在添加依赖的时候，要小心不要有循环依赖。