5
为什么不使用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的性能与竞争对手相比不佳的信息。 …