为什么不使用java.util.logging?
我有生以来第一次发现自己正在写一个将开源的Java API。希望将其包含在许多其他项目中。 对于日志记录,我(实际上是与我一起工作的人)一直使用JUL(java.util.logging),并且从未遇到过任何问题。但是,现在我需要更详细地了解我应该为API开发做什么。我对此进行了一些研究,并根据所获得的信息感到更加困惑。因此,这个职位。 由于我来自七月,所以我对此有偏见。我对其余的知识并不多。 通过研究,我得出了人们不喜欢JUL的这些原因: “我很早在Sun发布JUL之前就开始使用Java进行开发,对于我而言,继续使用logging-framework-X而不是学习新知识变得更加容易”。嗯 我不是在开玩笑,这实际上是人们所说的。有了这个论点,我们所有人都可以做COBOL。(但是我当然可以认为自己是个懒惰的家伙) “我不喜欢JUL中的日志记录级别的名称”。好的,认真的说,这还不足以引入新的依赖关系。 “我不喜欢JUL输出的标准格式”。嗯 这只是配置。您甚至不必执行任何代码明智的事情。(是的,过去,您可能必须创建自己的Formatter类才能正确使用它)。 “我使用了其他也使用logging-framework-X的库,因此我认为仅使用该库就更容易了”。这是一个循环的论证,不是吗?为什么“每个人”都使用logging-framework-X而不使用JUL? “其他人都在使用logging-framework-X”。对我来说,这只是上述情况的特例。多数并不总是正确的。 因此,真正的大问题是为什么不选择JUL?。我错过了什么?记录正面(SLF4J,JCL)的理由是,历史上已经存在多种记录实现,其原因确实可以追溯到我看到的JUL之前的时代。如果JUL是完美的,那么将不会存在伐木外观,还是什么?使事情更加混乱的是,JUL在某种程度上是一种外观,它允许交换Handlers,Formatters甚至LogManager。 而不是采用多种方式做同一件事(记录),我们是否应该首先质疑为什么必须这样做?(并查看这些原因是否仍然存在) 好的,到目前为止,我的研究已经发现了一些可能是JUL 真正问题的东西: 表现。有人说SLF4J的性能优于其他产品。在我看来,这似乎是过早优化的一种情况。如果您需要每秒记录数百兆字节,那么我不确定您是否走在正确的道路上。JUL也已经发展,您在Java 1.4上进行的测试可能不再正确。您可以在此处阅读有关此内容的信息,此修复程序已将其纳入Java7。许多人还谈到了日志记录方法中字符串连接的开销。但是,基于模板的日志记录避免了这种成本,并且它在JUL中也存在。我个人从来没有真正写过基于模板的日志记录。太懒了。例如,如果我使用JUL执行此操作: log.finest("Lookup request from username=" + username + ", valueX=" + valueX + ", valueY=" + valueY)); 我的IDE会警告我,并请求允许将其更改为: log.log(Level.FINEST, "Lookup request from username={0}, valueX={1}, valueY={2}", new Object[]{username, valueX, valueY}); ..我当然会接受。许可授予 !感谢您的帮助。 因此,我实际上并不是自己编写此类语句,而是由IDE完成的。 总之,在性能问题上,我没有发现任何暗示JUL的性能与竞争对手相比不佳的信息。 …