Why not use java.util.logging?

by

Disclaimer: I am the founder of log4j, SLF4J and logback projects.

There are objective reasons for preferring SLF4J. For one, SLF4J allows the end-user the liberty to choose the underlying logging framework. In addition, savvier users tend to prefer logback which offers capabilities beyond log4j, with j.u.l falling way behind. Feature-wise j.u.l may be sufficient for some users but for many others it just isn’t. In a nutshell, if logging is important to you, you would want to use SLF4J with logback as the underlying implementation. If logging is unimportant, j.u.l is fine.

However, as an oss developer, you need to take into account the preferences of your users and not just your own. It follows that you should adopt SLF4J not because you are convinced that SLF4J is better than j.u.l but because most Java developers currently (July 2012) prefer SLF4J as their logging API. If ultimately you decide not to care about popular opinion, consider the following facts:

  1. those who prefer j.u.l do so out of convenience because j.u.l is bundled with the JDK. To my knowledge there are no other objective arguments in favor of j.u.l.
  2. your own preference for j.u.l is just that, a preference.

Thus, holding “hard facts” above public opinion, while seemingly brave, is a logical fallacy in this case.

If still not convinced, JB Nizet makes an additional and potent argument:

Except the end user could have already done this customization for his
own code, or another library that uses log4j or logback. j.u.l is
extensible, but having to extend logback, j.u.l, log4j and God only
knows which other logging framework because he uses four libraries that
use four different logging frameworks is cumbersome. By using SLF4J, you
allow him to configure the logging frameworks he wants, not the one
you have chosen. Remember that a typical project uses myriads of
libraries, and not just yours.

If for whatever reason you hate the SLF4J API and using it will snuff the fun out of your work, then by all means go for j.u.l. After all, there are means to redirect j.u.l to SLF4J.

By the way, j.u.l parametrization is at least 10 times slower than SLF4J’s which ends up making a noticeable difference.

More Related Contents:

  1. How to use MDC with thread pools?
  2. Logback to log different messages to two files
  3. Disable the log from specific class/jar via logback.xml
  4. Dropwizard doesn’t log custom loggers to file
  5. Configuring Log4j Loggers Programmatically
  6. How to configure slf4j-simple
  7. Is it worth to use slf4j with log4j2
  8. How to send java.util.logging to log4j?
  9. How can I configure Logback to log different levels for a logger to different destinations?
  10. Send/redirect/route java.util.logging.Logger (JUL) to Logback using SLF4J?
  11. How to change root logging level programmatically for logback
  12. Logging framework incompatibility
  13. JUL to SLF4J Bridge
  14. Redirect System.out and System.err to slf4j
  15. Are there technical reasons to prefer using logback instead of log4j?
  16. Rolling logback logs on filesize and time
  17. How to intercept SLF4J (with logback) logging via a JUnit test?
  18. Spring Boot, logback and logging.config property
  19. Setting Logback Appender path programmatically
  20. logback: Two appenders, multiple loggers, different levels
  21. Logback – set log file name programmatically
  22. Logback – set log file name programmatically
  23. SLF4J – Logback: How to configure loggers in runtime?
  24. How can I log SQL statements in Spring Boot?
  25. Selenium many Logs (How to remove)
  26. In log4j, does checking isDebugEnabled before logging improve performance?
  27. How to send a stacktrace to log4j?
  28. Where is the “server log” for Tomcat when running externally from IntelliJ Ultimate?
  29. What is a simple, effective way to debug custom Kafka connectors?
  30. Print full call stack on printStackTrace()?

Leave a Comment