5 回答

• 172

  Disclaimer ：我是log4j，SLF4J和logback项目的创始人 .

  偏爱SLF4J有客观原因 . 一个， SLF4J allows the end-user the liberty to choose the underlying logging framework . 此外，更精明的用户往往更喜欢logback which offers capabilities beyond log4j，j.u.l落后 . 对于某些用户来说，功能方面的j.u.l可能就足够了，但对于其他许多用户而言，它可能就足够了 . 简而言之，如果日志记录对您很重要，您可能希望将SLF4J与logback一起用作底层实现 . 如果日志记录不重要，j.u.l就可以了 .

  但是，作为oss开发人员，您需要考虑用户的偏好而不仅仅是您自己的偏好 . 因此你应该采用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并且上帝只知道哪个其他日志框架，因为他使用了四个使用四个不同日志框架的库是麻烦的 . 通过使用SLF4J，您可以让他配置他想要的日志框架，而不是您选择的日志框架 . 请记住，一个典型的项目使用无数的库，而不仅仅是你的 .

  如果出于某种原因你讨厌SLF4J API并使用它会消除你工作的乐趣，那么一定要去j.u.l.毕竟，有办法redirect j.u.l to SLF4J .

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

  回复于 2024-04-25T18:05:40+08:00
• 27

  我开始像我怀疑的那样，使用JUL，因为它是最容易立即开始的 . 然而，多年来，我已经希望我花了一点时间选择 .

  我现在的主要问题是我们有大量的“库”代码，这些代码在许多应用程序中使用，它们都使用JUL . 每当我在Web服务类型的应用程序中使用这些工具时，日志记录就会消失或变得无法预测或奇怪 .

  我们的解决方案是为库代码添加一个外观，这意味着库日志调用没有改变，但是被动态地重定向到可用的任何日志记录机制 . 当包含在POJO工具中时，它们被定向到JUL，但当部署为Web应用程序时，它们被重定向到LogBack .

  我们的遗憾 - 当然 - 库代码不使用参数化日志记录，但现在可以在需要时对其进行改造 .

  我们使用slf4j来构建外观 .

  回复于 2024-04-25T18:05:40+08:00
• 1

  • java.util.logging 是在Java 1.4中引入的 . 在此之前有记录用途，当释放1.4时，'s why many other logging APIs exist. Those APIs where used heavily before Java 1.4 and thus had a great marketshare that didn't只会降到0 .

  • JUL没有开始那么好，很多你提到的东西在1.4中差很多而且只在1.5中变得更好（我猜在6中也是如此，但我不太确定） .

  • JUL不适 Contract 一JVM中具有不同配置的多个应用程序（想想不应该交互的多个Web应用程序） . Tomcat需要跳过一些箍来实现这一点（如果我理解正确的话，有效地重新实现JUL） .

  • 您无法始终影响库使用的日志记录框架 . 因此，使用SLF4J（实际上只是一个非常薄的API层，高于其他库）有助于保持整个日志世界的一致性（因此您可以决定底层日志框架，同时仍在同一系统中进行库日志记录） .

  • 图书馆不能轻易改变 . 如果以前版本的库曾经使用过logging-library-X，它就不能轻易切换到logging-library-Y（例如JUL），即使后者显然是优等的：该库的任何用户都需要学习新的日志记录框架和（至少）重新配置他们的日志记录 . 这是一个很大的禁忌，特别是当它给大多数人带来明显的收益时 .

  尽管如此，我认为JUL至少是目前其他日志框架的有效替代品 .

  回复于 2024-04-25T18:05:40+08:00
• 26

  我通过logback-1.1.7对抗slf4j-1.7.21，输出到SSD，Java 1.8，Win64

  jul运行48449 ms，对于1M循环，回溯27185 ms .

  不过，更快的速度和更好的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);
      }
  
  }
  

  回复于 2024-04-25T18:05:40+08:00
• 4

  恕我直言，使用像slf4j这样的日志门面的主要优点是你让图书馆的最终用户选择他想要的具体日志记录实现，而不是将你的选择强加给最终用户 .

  也许他已经在Log4j或LogBack（特殊格式化程序，appender等）上投入了时间和金钱，并且更喜欢继续使用Log4j或LogBack，而不是配置jul . 没问题：slf4j允许这样做 . 使用Log4j比jul更明智吗？也许，也许不是 . 但你不在乎 . 让最终用户选择他喜欢的东西 .

  回复于 2024-04-25T18:05:40+08:00