你觉得java.util.logging足够了吗？[已关闭]

java.util.logging （jul） 从一开始就是不必要的。忽略它。

jul本身具有以下缺点：

• 在Java 1.4中引入7月时，已经有一个广泛使用的完善的日志记录框架：LOG4J
• 预定义的日志级别为：严重、警告、信息、配置、精细、精细、最精细。我不会告诉你我个人对这些预定义级别的看法，以保持这个答案的半客观性。
• 可以定义其他级别。jul支持高达4G不同的日志级别，这有点过分，恕我直言。少即是多。

• 最重要的一点：如果您敢于定义自己的日志级别，则可能会遇到内存泄漏问题！
  请随时在此处阅读有关此效果的信息：

  • Classloader泄漏：可怕的“java.lang.OutOfMemoryError：PermGen空间”异常
  • 如何修复可怕的“java.lang.OutOfMemoryError： PermGen space”异常（类加载器泄漏）

  这是一个非常有趣的阅读，即使你不打算使用自定义级别，顺便说一句，因为问题是一个广泛的问题，根本不适用于7月。

• 它驻留在 java.* 命名空间中，因此无法在运行时交换实现。这有效地防止了它桥接到SLF4J，就像在commons.logging和LOG4J的情况下一样。7月的桥接方式会影响性能。这使得 jul 成为最不灵活的日志记录框架。
• 通过引入 jul，Sun 隐式地将其定义为“标准 java 日志记录框架”。这导致了一个普遍的误解，即一个“优秀的Java公民”应该在他们的库或应用程序中使用jul。
  情况恰恰相反。
  如果你使用 commons.logging 或 LOG4j，你可以通过桥接到 SLF4J 来交换实际使用的日志记录框架，如果需要的话。这意味着使用 commons.logging、LOG4J 或 SLF4J 的库都可以记录到同一个日志记录目标，例如 file。

我个人建议将SLF4J + Logback组合用于所有日志记录目的。这两个项目都由LOG4J背后的Ceki Gülcü协调。
SLF4J是commons.logging的有价值的（但非官方的，因为它不是来自同一组）的继承者。它比 CL 问题更少，因为它静态解析实际使用的日志记录后端。另一方面，
Logback是LOG4J的（非）官方继承者。它以本机方式实现SLF4J，因此没有任何包装器造成的开销。

现在，如果你仍然认为我应得的，你可以否决我。;)

记录与第三方库的依赖关系

在大多数情况下，Java JDK日志记录本身是不够的。但是，如果您有一个使用多个开源第三方库的大型项目，您将很快发现其中许多库具有不同的日志记录依赖项。

正是在这些情况下，从日志记录实现中抽象出日志记录 API 的需求变得非常重要。我建议使用slf4j或logback（使用slf4j API）作为你的API，如果你想坚持使用Java JDK日志记录，你仍然可以！Slf4j可以毫无问题地输出到许多不同的记录器实现。

在最近的一个项目中，它的有用性发生了一个具体的例子：我们需要使用需要log4j的第三方库，但我们不想并排运行两个日志记录框架，所以我们使用了slf4j log4j api包装库，问题得到了解决。

总而言之，Java JDK日志记录很好，但是从长远来看，在我的第三方库中使用的标准化API将节省您的时间。试着想象重构每个日志记录语句！