为什么不使用java.util.logging呢?

小开

java.util.logging在Java 1.4中引入。在此之前，伐木也有用途。这就是存在许多其他日志api的原因。这些api在Java 1.4之前被大量使用，因此在1.4发布时，它们的市场份额并没有下降到零。
JUL一开始并没有那么好。你提到的很多东西在1.4中都很糟糕，在1.5中才有所改善(我猜在6中也一样，但我不太确定)。
JUL不太适合同一个JVM中具有不同配置的多个应用程序(想想不应该交互的多个web应用程序)。Tomcat需要通过一些步骤才能使其工作(如果我理解正确的话，可以有效地重新实现JUL)。
你不能总是影响你的库使用什么日志框架。因此，使用SLF4J(它实际上只是一个非常薄的API层，位于其他库之上)有助于保持整个日志记录世界的一致性(因此，您可以决定底层日志记录框架，同时在同一系统中仍然具有库日志记录)。
库不能轻易更改。如果以前版本的库使用logging-library-X，那么它就不能轻易切换到logging-library-Y(例如JUL)，即使后者明显更好。该库的任何用户都需要学习新的日志框架，并且(至少)重新配置他们的日志。这是一个大禁忌，尤其是当它没有给大多数人带来明显的好处时。

说了这么多，我认为JUL是至少，是当今其他日志框架的有效替代品。

小开

以我之见，使用slf4j这样的日志facade的主要优势在于，您可以让库的最终用户选择他想要的具体日志实现，而不是将您的选择强加给最终用户。

也许他已经在Log4j或LogBack(特殊的格式化程序、附加程序等)上投入了时间和金钱，并且更愿意继续使用Log4j或LogBack，而不是配置july .没问题:slf4j允许这样做。使用Log4j而不是jul是明智的选择吗?也许，也许不是。但你不在乎。让最终用户选择他喜欢的。

小开

最佳答案

免责声明:我是log4j, SLF4J和logback项目的创始人。

偏爱SLF4J是有客观原因的。首先，SLF4J允许最终用户自由选择底层日志记录框架。此外，精明的用户往往更喜欢Logback提供了log4j之外的功能，而j.u.l则远远落后。有特色的j.u.l可能对某些用户来说已经足够了，但对其他许多用户来说还不够。简而言之，如果日志记录对您很重要，那么您将希望使用带日志返回的SLF4J作为底层实现。如果日志不重要，那么j.u.l就可以了。

然而，作为一个操作系统开发者，你需要考虑用户的偏好，而不仅仅是你自己的。因此，你应该采用SLF4J，不是因为你相信SLF4J比j.u.l更好，而是因为大多数Java开发人员目前(2012年7月)更喜欢SLF4J作为他们的日志API。如果你最终决定不去在意大众的意见，考虑一下以下事实:

那些更喜欢j.u.l的人这样做是出于方便，因为j.u.l是与JDK捆绑在一起的。据我所知，没有其他客观的论据支持j。u。l。
你自己对j.u.l的偏好就是的偏好。

因此，将“确凿的事实”置于公众舆论之上，虽然看似勇敢，但在这种情况下却是一个逻辑谬误。

如果仍然不相信，JB Nizet会做一个额外的有力的论证:

除非最终用户已经为他的用户做了这个定制自己的代码，或者使用log4j或logback的另一个库。j.u.l是可扩展的，但必须扩展logback, j.u.l, log4j和God 知道哪个日志框架，因为他使用了四个库使用四种不同的日志框架是很麻烦的。通过使用SLF4J，您可以允许他配置他想要的日志框架，而不是只配置一个你已经选择了。记住，一个典型的项目使用无数的图书馆，而不仅仅是你的.
.
.

如果出于某种原因，你讨厌SLF4J API，使用它会让你的工作失去乐趣，那么无论如何都要选择j.u.l。毕竟，有重定向j.u.l到SLF4J的方法。

顺便说一下，j.u.l参数化至少比SLF4J慢10倍，这最终产生了明显的差异。

小开

我开始使用JUL，我怀疑，因为它是最容易立即上手的。然而，这些年来，我开始希望自己当初多花一点时间来做选择。

我现在的主要问题是，我们有大量的“库”代码，在许多应用程序中使用，他们都使用july .每当我在web服务类型的应用程序中使用这些工具时，日志就会消失或到不可预测或奇怪的地方。

我们的解决方案是向库代码添加一个facade，这意味着库日志调用不会改变，而是被动态重定向到任何可用的日志机制。当包含在POJO工具中时，它们被定向到JUL，但当部署为web应用程序时，它们被重定向到LogBack。

当然，我们的遗憾是库代码没有使用参数化日志记录，但现在可以在需要时进行改进。

我们使用slf4j来构建facade。

小开

我通过logback-1.1.7在slf4j-1.7.21上运行jul，输出到SSD, Java 1.8, Win64

jul运行48449毫秒，logback 27185毫秒为1M循环。

尽管如此，对我来说，稍微快一点和更好一点的API还是不值3个库和800K。

package log;


import java.util.logging.Level;
import java.util.logging.Logger;


public class LogJUL
{
final static Logger logger = Logger.getLogger(LogJUL.class.getSimpleName());


public static void main(String[] args)
{
int N = 1024*1024;


long l = System.currentTimeMillis();


for (int i = 0; i < N; i++)
{
Long lc = System.currentTimeMillis();


Object[] o = { lc };


logger.log(Level.INFO,"Epoch time {0}", o);
}


l = System.currentTimeMillis() - l;


System.out.printf("time (ms) %d%n", l);
}
}

而且

package log;


import org.slf4j.Logger;
import org.slf4j.LoggerFactory;


public class LogSLF
{
static Logger logger = LoggerFactory.getLogger(LogSLF.class);




public static void main(String[] args)
{
int N = 1024*1024;


long l = System.currentTimeMillis();


for (int i = 0; i < N; i++)
{
Long lc = System.currentTimeMillis();


logger.info("Epoch time {}", lc);
}


l = System.currentTimeMillis() - l;


System.out.printf("time (ms) %d%n", l);
}


}

小开

JUL的原因:

用户不友好的API设计-笨拙的消息参数语法，奇怪的日志级别定义…这样的例子不胜枚举。
这是一个日志实现，而不是Facade。

正如引用的博客文章所指出的，这不是Java 9系统的目标。Logger定义用于日志记录的通用接口。SLF4J和Apache Commons Logging都尝试过这样的Facade目标，但是在我看来，它们都失败了，因为它们提供了太多的实现，而不是坚持定义良好的日志Facade这一简单目标。例如，一个真正的日志facade永远不会在“性能”方面与任何日志实现进行比较。因为facade本身不需要记录日志。

声明:对于日志facade，我重新发明了轮子，并使用了我自己的https://github.com/elf4j

为什么不使用java.util.logging呢?

测试性能

测试性能(第二部分)

最终结论

最终的结论(可能)