Ceki Gülcü在 Java 日志领域世界知名。他创造了 Log4J ,这个最早的 Java 日志框架即便在 JRE 内置日志功能的竞争下仍然非常流行。随后他又着手实现 SLF4J 这个“简单的日志前端接口(Façade)”来替代 Jakarta Commons-Logging 。
在过去的一年中,Ceki 在从事他的新项目,LOGBack,一个“可靠、通用、快速而又灵活的 Java 日志框架”。自一年前发布 0.1 alpha 版以来,LOGBack 已经取得了长足的进步。1.0 版即将发布,又有早期用户的正面评价,我们也应该仔细看看 LOGBack,到底适不适合我们的需要。
Xavier Hanin 谈论了他使用 LOGBack 的经验:
我已经用了 LOGBack 几个月,我被它打动了。文档和支持都很完善,日志功能简洁利落,性能表现也说得上风驰电掣,还有创新的 Eclipse 插件,我终于给劳苦功高的 Log4J 找到了接班人。
Rob Willams 补充说:
噢,还有,我们当初毅然决定采用 LogBack。爱死它了。整个过渡过程一点麻烦都没有,我们绝对喜欢它的新语法。
他所说的新语法让 LOGBack 能够处理许多复杂的日志语句,而不再需要事先检查日志级别(logging level),同时性能上的影响微不足道。比如在 Log4J 里面,你可能会这样写:
if( logger.isDebugEnabled() ) { <br></br> logger.debug( "User with account " + <br></br> user.getAccount() + " failed authentication; " + <br></br> "supplied crypted password " + user.crypt(password) + <br></br> " does not match." ); <br></br> } <br></br>
等价的 LOGBack 语句如下:
logger.debug( "User with account {} failed authentication; " + <br></br> "supplied crypted password {} does not match.", <br></br> user.getAccount(), user.crypt(password) ); <br></br>
LOGBack 把拼装消息的代价推迟到它能够确定是不是要显示这条消息的时候。不过获取参数的高昂代价并没有被推迟支付,比如上例中的密码加密。
LOGBack 还声称自己性能更佳:
某些关键操作,比如判定是否记录一条日志语句的操作,其性能得到了显著的提高。这个操作在 LOGBack 中需要 3 纳秒,而在 Log4J 中则需要 30 纳秒。LOGBack 创建记录器(logger)的速度也更快:13 毫秒,而在 Log4J 中需要 23 毫秒。更重要的是,它获取已存在的记录器只需 94 纳秒,而 Log4J 需要 2234 纳秒,时间减少到了 1/23。跟 JUL 相比的性能提高也是显著的。
LOGBack 还可以被集成,目前已经有了一个 Eclipse 插件和一个 JMX Configurator Bean。
InfoQ 就 LOGBack 访问了 Ceki,第一个问题是大家都关心的:为什么要建立另一个日志框架,而不是把这些改进放到 Log4J 中去?
我当时(今天也还部分地)觉得在 Apache Logging Services 项目之外做创新会容易一些。不要误会我的意思,我对 Apache Software Foundation 的评价很高,它是一个独特的,而且在很多方面都极其出色的组织。谁也说不定,可能有一天 SLF4J 和 LOGBack 成为日志领域新的事实标准的时候,会重新融入 Apache。
关于 SLF4J 的接受程度:
现在有几个重量级项目,比如 Hibernate、Jetty、Spring-OSGi 和 Wicket 都已经迁移到了 SLF4J API,我可以毫不惭愧地说,SLF4J 的吸引力不可忽视。SLF4J 正在四处冒出头来,虽然 Jakarta Commons Logging(JCL)这个广泛使用的类库,在 Apache 品牌的温暖阳光沐浴下,占据着整个疆域。考虑到开始时的劣势,SLF4J 现在的表现已经超过了我们的预期。
当被问到如何比较 LOGBack 的免费文档,和 Log4J 那种小部分免费大部分商业的文档时:
如你所说,Log4J 只提供了有限的免费文档,完善的文档则需要付费。对于 LOGBack,我们采纳了另一种途径,我们所有的文档都可以在我们的项目网站上直接看到,获取也完全免费,这给了 Java 开发者们又一个理由转移到 LOGBack。另外,LOGBack 的市场占有率比 Log4J 要低一个数量级,销售 LOGBack 的文档没有任何经济上的意义。为了保证项目的长期经济支持,我们开发了一个跟 LOGBack 稍稍相关的产品,过几周就会推出。我们对 LOGBack 的长期计划是不搞任何噱头,把它发展成一个合作性的开源项目。至于“合作性”,我的意思是开方给所有开发者作贡献,而不局限于现在的开发团队。
请说说离 1.0 版发布还差些什么:
对于即将到来的 1.0 版,大部分重要的东西都已经齐备了。我们还要修复很多错误,但主要的工作还是完善文档,做更多的测试,一再重复做这些事情。我说过要完善文档没?在日志这个领域还有很多东西需要我们去做,可能要好几代人才能完成。我们已经逐渐看清了前面的路途,希望能够给未来铺平一些道路。
当被问到 LOGBack 有哪些能够吸引开发者的地方:
没有绝对的答案。有些用户可能会觉得性能是一个值得转移到 LOGBack 的理由,其他人可能觉得 Log4J 已经不错。虽然我和其他 LOGBack 开发者们正努力给用户更多的理由,不过我们中间很多人对于能够从事一个强调质量的软件项目已经很满意。我们必须“吃我们自己的狗食”,并在这个过程中得到有价值的软件开发技能——按今天的标准来说并不坏。考虑到 LOGBack 项目的出发点正是 Log4J 项目的不及之处,只要我们持续不断地改进 LOGBack,我们相信一定会有越来越多的 Java 开发者接受 SLF4J/LOGBack 的组合。
因为 SLF4J 和 LOGBack 可以桥接其他竞争性的 API,开发者们可以在他们的项目中用 LOGBack 替换 Log4J(通过 log4j-bridge.jar)和 Jakarta Commons-Logging(通过 jcl104-over-slf4j.jar),因而不必仅仅为了使用 LOGBack 而被迫在同一个项目中配置好几个日志框架。
关于 LOGBack 和 SLF4J 的更多信息请阅读 Ceki 的《十个转移到LOGBack 的理由》,或者持续关注InfoQ 的 Java 社区。
查看英文原文: LOGBack: Evolving Java Logging
评论