java.util.logging_为什么不使用java.util.logging？

在我的生活中第一次，我发现自己在一个位置，我在写一个Java API将开源。希望被包括在许多其他项目。

对于日志记录我(以及确实是我工作的人)总是使用JUL(java.util.logging)，从来没有任何问题。但现在我需要更详细地了解我应该为我的API开发做什么。我已经做了一些研究这个和信息，我有我只是得到更多的困惑。因此这篇文章。

因为我来自JUL我有偏见。我的余下的知识不是那么大。

从我做的研究，我想出了为什么人们不喜欢JUL的这些原因：

>“我在Java发布JUL之前就开始开发Java，它只是更容易继续使用logging-framework-X，而不是学习新的东西。嗯。我不是开玩笑，这其实是人们说的。有了这个参数，我们可以做COBOL。 (但我可以肯定地说，这是一个懒惰的家伙自己)

>“我不喜欢JUL中日志记录级别的名称”。好吧，认真，这只是不足以引入一个新的依赖。

>“我不喜欢JUL输出的标准格式”。嗯。这只是配置。你甚至不需要做任何代码。 (真的，回到过去，你可能不得不创建自己的Formatter类，以获得正确)。

>“我使用其他库也使用logging-framework-X，所以我以为它更容易使用那个”。这是一个循环的参数，不是？为什么“everybody”使用logging-framework-X而不是JUL？

>“其他人都在使用logging-framework-X”。这对我来说只是上面的一个特例。多数并不总是正确的。

所以真正的大问题是为什么不是JUL？我错过了什么？日志外观(SLF4J，JCL)的存在理由是，历史上存在多个日志记录实现，其原因真的可以追溯到JUL之前的时代，因为我看到它。如果JUL是完美的，那么日志外观不会存在，或什么？而不是拥抱他们不应该问我们为什么他们是必要的第一位？ (并看看这些原因是否仍然存在)

好吧，我的研究到目前为止导致了一些我可以看到的事情可能是真正的问题与JUL：

>性能。有人说，SLF4J的性能优于其余。这似乎是一个过早优化的情况。如果你需要记录数百兆字节每秒，那么我不知道你是否在正确的路径。 JUL也发展了，你对Java 1.4的测试可能不再是真的。你可以阅读它的here和这个修复已经使其成Java 7.许多人还谈论在记录方法中字符串连接的开销。然而基于模板的日志记录避免了这种成本，它也存在于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的表现不是比竞争对手确定。

>从类路径配置。开箱即用的JUL无法从类路径加载配置文件。它是一个few lines of code使它这样做。我可以看到为什么这可能是恼人，但解决方案是简单和短。

>输出处理程序的可用性。 JUL提供了5个输出处理程序：控制台，文件流，套接字和内存。这些可以扩展或可以写入新的。这可以例如写入UNIX / Linux系统日志和Windows事件日志。我个人从来没有这个要求，也没有看到它使用，但我可以肯定地说，为什么它可能是一个有用的功能。例如，Logback带有Syslog的附加器。仍然我会说

>输出目的地的需求的99.5％由JUL开箱即用。

>特殊需求可以由定制处理程序在JUL顶部，而不是在别的东西。对我来说，没有什么，建议它需要更多的时间来写一个Syslog输出处理程序的JUL，而不是另一个日志框架。

我真的很担心，有一些我忽略了。除了JUL之外，使用日志外观和日志实现非常普遍，我必须得出结论，这是我只是不理解的。这不会是第一次，恐怕。 🙂

那么我应该怎么做我的API？我希望它成功。我当然可以“与流动”，并执行SLF4J(这似乎是最流行的这些天)，但为了我自己的缘故，我仍然需要了解什么是今天的JUL是什么错误，保证所有的毛绒？我会通过为我的图书馆选择JUL来破坏自己吗？

测试性能

(nolan600于2012年7月7日添加的部分)

下面有一个参考从Ceki关于SLF4J的参数是10倍或更快比JUL的。所以我开始做一些简单的测试。乍一看，索赔肯定是正确的。这里是初步的结果(但阅读！)：

>执行时间SLF4J，后端Logback：1515

>执行时间SLF4J，后端JUL：12938

>执行时间JUL：16911

上面的数字是毫秒，所以越小越好。所以10倍的性能差异是首先实际相当接近。我的初步反应：这是很多！

这里是测试的核心。可以看出，一个整数和一个字符串在循环中被解析，然后在log语句中使用：

for (int i = 0; i < noOfExecutions; i++) {

for (char x=32; x<88; x++) {

String someString = Character.toString(x);

// here we log

}

}

(我想要日志语句有一个原始数据类型(在这种情况下为一个int)和一个更复杂的数据类型(在这种情况下是一个字符串)。不确定它很重要，但你有它。

SLF4J的日志语句：

logger.info("Logging {} and {} ", i, someString);

JUL的日志语句：

logger.log(Level.INFO, "Logging {0} and {1}", new Object[]{i, someString});

在进行实际测量之前，用相同的测试执行一次JVM“加热”。 Java 1.7.03在Windows 7上使用。使用最新版本的SLF4J(v1.6.6)和Logback(v1.0.6)。 Stdout和stderr重定向到空设备。

然而，现在小心，结果是JUL花费大部分时间在getSourceClassName()，因为JUL默认打印输出中的源类名称，而Logback不。所以我们比较苹果和橘子。我必须再次做测试，并以类似的方式配置日志实现，以便他们实际输出相同的东西。但我怀疑SLF4J Logback仍然会出现在顶部，但远离上面给出的初始数字。敬请关注。

Btw：测试是我第一次实际使用SLF4J或Logback。愉快的经验。当你开始的时候，JUL肯定不那么热情。

测试性能(第2部分)

(2012年8月8日由nolan600添加的部分)

事实证明，它并不重要的性能如何配置您的模式在JUL，即，是否包括源名称或不。我尝试了一个非常简单的模式：

java.util.logging.SimpleFormatter.format="%4$s: %5$s [%1$tc]%n"

并没有改变上述时间。我的分析器显示，记录器仍然花费大量的时间在调用getSourceClassName()，即使这不是我的模式的一部分。模式没有关系。

因此我总结了性能问题，至少对于测试的基于模板的日志语句似乎在JUL(慢)和SLF4J Logback(quick)之间的实际性能差异中大约有10倍。就像Ceki说的。

我还可以看到另一个事情，即SLF4J的getLogger()调用比JUL的同上更昂贵。 (95 ms对0.3 ms，如果我的profiler是准确的)。这是有道理的。 SLF4J必须在底层日志实现的绑定上做一些时间。这不吓唬我。这些调用在应用程序的生命周期中应该很少见。坚牢度应该在实际的日志调用中。

定论

(2012年8月8日由nolan600添加的部分)

谢谢你的所有答案。与我最初认为我最终决定使用SLF4J为我的API相反。这是基于一些事情和您的输入：

>它可以灵活地在部署时选择日志实现。

>在应用程序服务器中运行时，JUL配置缺乏灵活性的问题。

> SLF4J当然是一个很快，如上所述，特别是如果你把它与Logback耦合。即使这只是一个粗略的测试，我有理由相信，在SLF4J Logback上的优化比在JUL上更多的努力。

>文档。 SLF4J的文档非常全面和精确。

>模式灵活性。正如我做的测试，我开始使JUL模仿Logback的默认模式。此模式包括线程的名称。事实证明，JUL不能做到这一点开箱即用。好吧，我还没有错过它，直到现在，但我不认为这是一个应该从日志框架丢失的事情。期！

>大多数(或许多)Java项目今天使用Maven，所以添加依赖不是那么大，特别是如果该依赖是相当稳定的，即不会不断地改变它的API。这似乎是真的对SLF4J。此外SLF4J罐和朋友的大小。

所以奇怪的事情发生了，我实际上已经与JUL在与SLF4J工作了一点后感到非常失望。我仍然感到遗憾的是，它必须这样与JUL。 JUL远非完美，但是有工作。只是不够好。同样可以说属性作为一个例子，但我们不考虑抽象，所以人们可以插入自己的配置库和你有什么。我认为原因是属性刚好在酒吧，而相反的是真实的今天的JUL …在过去它进入零，因为它不存在。