1.1 日志框架历史
1.2 log4j
很多年前,一个叫
Ceki Gülcü
的大佬在一个项目中开发跟踪 API,这套跟踪 API 逐步演变成log4j
, 大概1999年,log4j
成为 Apache 的一员。
1.3 JUL
Apache 觉得
log4j
很有价值,就推荐给 SUN 公司(Java 语言是由 SUN 公司的 James Gosling 发明的),希望 SUN 公司在 JDK 中加入 log4j,SUN 公司觉得加入日志 API 很有必要,但是又看不上 log4j,于是便自己搞了一套官方的,于 2002 年 JDK 1.4 中实现了JUL
(Java Util Logging)。
此时,市面上就有两套日志 API:来自 Apache 的 log4j
和来自官方的 JUL
。
1.4 JCL
log4j
和 JUL
是两套不同的 API。一个出现较早、一个是官方的,两个用户群体都较大。如果在项目中想要切换日志框架就需要改动大量代码,同时这也不符合”面向接口编程“的设计原则。Apache 就推出了 JCL(Jakarta Commons Logging) 项目,名字看着高大上,但这玩意儿就是在 SSH、SSM 时代到处都能看见,那就是搭建框架时经常会看到的 commons-logging
包,该项目是一套日志的抽象层(后来大神们针对这种日志的抽象层一个高端的名字——日志门面)。所谓”抽象层“,本质上就是一堆接口,有接口就需要有实现,没有实现那就是自娱自乐,没有鸟用。所以 Apache 针对 JCL 提供了一个默认实现,那就是 Simple Log
。
JCL
基于动态绑定来实现日志的记录:开发过程中使用 JCL 定义的接口,程序运行的时候使用类路径 classpath 中的具体实现(Simple Log、log4j、JUL)。可以和 JDBC 类比,Java 官方制定了数据库访问层持久化操作的标准 JDBC,各个数据库厂商(Oracle、MySQL等)实现这套标准。JCL 也是想成为规范制定者,统一日志操作的规范。
JCL
的出现,日志体系显得比较优雅,面向 JCL 的接口编程,可以很方便的切换日志框架。在这个时候,log4j他爹
Ceki`因为一些未知的原因离开了 Apache。
1.5 SLF4J
写代码的人大多有个共性:别人写的都是垃圾、自己昨天写的代码也是垃圾,只有自己现在写的才是最好的。
Ceki
这哥们同样觉得 JCL 不是特别完美,于是自己又搞了一套新版本的日志接口(高端的名字是:日志门面):SLF4J(Simple Logging Facade for Java)
。
问题来了,slf4j 只有接口没有实现,难不成要让 log4j 和 JUL 都来实现 slf4j 吗?肯定是不可能的。
JCL 是采用动态绑定机制,而 slf4j 采用”桥接包“,也就是分别开发 log4j 和 JUL 的桥接包,通过桥接包来适配两者。大牛就是大牛,
Ceki
提供了这些桥接包slf4j-log4j
、slf4j-jdk14
等。由于 JCL 出现比 slf4j 早,很多项目使用了 JCL,所以这大佬也提供了slf4j-jcl
。
还有一种常见:在某个项目中使用了一个第三方框架,这个项目使用了 slf4j 和 log4j,而依赖的第三方框架使用了 JCL 和 JUL,这时候系统就会有两种日志配置文件和两种打印方式,乱七八糟的。 Ceki Gülcü
也考虑到这种场景,没有他的桥接包搞不定的场景,于是就弄了个 jcl-over-slf4j
的桥接包...
1.6 Logback
Ceki Gülcü
弄了 slf4j 和一堆桥接包,2006 年为 slf4j 提供了一个很厉害的实现:logback。与此同时他还特意写了一篇文章《Reasons to prefer logback over log4j》。毕竟 log4j 也出自于他的手,里面存在什么问题他最清楚。事实上,logback 的性能和设计确实比 log4j 更厉害,与时俱进嘛。
1.7 Log4j2
Logback 的出现让 Apache 坐不住了,2012 年推出了新项目
log4j2
。看名字像是log4j
的升级版,实际上是一个全新的玩意,它不兼容log4j
。Log4j2 几乎包括了 Logback 的特性。竞争是残酷的,与slf4j
类似,log4j2
也想统一日志的天下,也弄了一堆桥接包,通过桥接包log4j-xxx
去兼容上面各种各样的日志框架。
核心就三个概念:
日志产品:log4j、JUL、logback、log4j2
日志门面:JCL、slf4j
桥接包:slf4j-xxx、log4j-xxx