49

It seems that log4j has some class loading issues (among others) and it seems to me the trend is to move out of log4j toward slf4j. (Hibernate stopped using the first in favor of the latter)

  1. Is it true?
  2. What are the main issues in log4j that slf4j solves?
  3. Is slf4j the final word or is there even a better "the next next log4j" industry standard?

Update:

  • So this answer by delfuego confuses me, can you accept / object it?:

You appear to have stumbled upon the major problem with log4j (and the Apache Commons Logging library), namely that they have a ridiculously hard time discovering and interacting with the right classloaders as they're being used. There's a very dense explanation, complete with examples, here; the take-home message is that one of the primary driving forces for the new logging framework SLF4J was to eliminate these issues entirely. You might want to swap it in and see if your life is made any easier.

ROMANIA_engineer
  • 54,432
  • 29
  • 203
  • 199
ruchirhhi
  • 609
  • 1
  • 5
  • 7
  • 4
    The article you reference at http://articles.qos.ch/classloader.html is not about classloading issues with log4j but rather with Jakarta Commons Logging (another logging facade). This is what SLF4J replaces with and bundles the code of the actual underlying logging system (including possibly log4j) to eliminate those class loading issues. – Kevin Brock Jan 14 '10 at 13:28
  • possible duplicate of [Should new projects use logback instead of log4j?](http://stackoverflow.com/questions/178836/should-new-projects-use-logback-instead-of-log4j) – ripper234 Nov 22 '11 at 09:44

6 Answers6

47

Slf4j is indeed just a logging facade. However, Log4j is intended to be succeeded by Logback, from the very same authors.

Update: if you'd like to know about another benefit of Slf4j, it's the fact that following (ugly) constructs aren't needed anymore to avoid the toString() unnecessarily been called:

if (logger.isDebugEnabled()) {
    logger.debug("Message: " + bigObject + ", " + anotherBigObject);
}

You can instead make use of parameterized messages:

logger.debug("Message: {}, {}", bigObject, anotherBigObject);

Also see What is the fastest way of (not) logging?

Carl Manaster
  • 39,912
  • 17
  • 102
  • 155
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • +1: I had a very similar question just some days back and started to use Logback which uses slf4j in the background. – lostiniceland Jan 14 '10 at 12:26
  • ?! varargs doesn't stop the execution of functions... does it? – Jason S Jan 14 '10 at 12:37
  • 4
    No, but it does stop the execution of toString which happens when you concatenate an object to the string. The main issue with logging being expensive isn't the call to the log function, it's the construction of the logged string! – Wouter Lievens Jan 15 '10 at 11:25
  • 2
    To be precise, logback is a fork of log4j by the original log4j founder, which he would like to succeed log4j. – Thorbjørn Ravn Andersen Feb 17 '11 at 09:26
  • @Wouter Yeah! You should use a logging library that have encoders for the objects passed, so no toString() is ever called and the contents of the object are copied straight to the byte buffer. MentaLog is one such logging library that produces no garbage at all by employing that strategy: http://mentalog.soliveirajr.com/posts/list/32.page – TraderJoeChicago Sep 24 '11 at 18:46
18

Slf4J is not an alternative for Log4j, but rather provides a Façade for logging, so one can you can plug in your own logging framework. It's mainly useful for libraries. from slf4j.org:

The Simple Logging Facade for Java or (SLF4J) serves as a simple facade or abstraction for various logging frameworks, e.g. java.util.logging, log4j and logback, allowing the end user to plug in the desired logging framework at deployment time.

To answer your question: Slf4j is being adopted by frameworks now, but in your projects, you can keep on using Log4J (or any other)

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
EJB
  • 2,383
  • 14
  • 15
  • So this answer is confusing: http://stackoverflow.com/questions/1974705/log4j-and-the-thread-context-classloader/1974775#1974775 it implies that slfJ solves issues created by Log4j after all... could it be that besides its Facade feature, it also has a good standalone native logging implementation better than log4j? – ruchirhhi Jan 14 '10 at 12:15
  • 1
    SLF4J requires a real logging implementation beneath it. This could still be Log4j, or you could use Logback, which natively implements the SLF4J interfaces (SLF4J and Logback are written by the same people). – SteveD Jan 14 '10 at 12:25
  • It is just a facade. There is, however, a new implementation called Logback, designed to be a first class implementation of SLF4J. It's worth noting that SLF4J, Log4J and Logback were all created by the same guy who basically sees Log4J as stalled. He has an account on StackOverflow (username is Ceki) and tends to restate this in most Log4J/SLF4J threads. – GaryF Jan 14 '10 at 12:26
  • 2
    Well the native implementations of Slf4J may be superior to Log4J, but the main purpose of it, is to decouple the choise of logging framework from the choise of application framework/ library. Just using Slf4J to wrap around Log4J won't fix your classloader issues. – EJB Jan 14 '10 at 12:28
  • @EJB: What class loader issues? The articles reference are about Jakarta Commons Logging. SLF4J on it's own, from what I read, cannot be superior to Log4J as it is not functional on it's own - it must be bundled with a real logging library (and one of those is, in fact, log4j). – Kevin Brock Jan 14 '10 at 13:31
  • From the website (www.slf4j.org), there are two 'native' (whatever that means) implementations for SLF4J: Logback and x4juli. In this post: http://stackoverflow.com/questions/1974705/log4j-and-the-thread-context-classloader/1974775#1974775 it is suggested that these handle certain classloading issues better. – EJB Jan 14 '10 at 14:15
7

First: an important point: Slf4j is the frontend logging (the API), which can use below most of the main loggin systems: log4j or java.util.logging for instance. So it is better to compared sfl4j to commons-logging.

About the state of Log4j, quotes from The state of java logging (one year ago)

One thing that I hadn't realized is that log4j development is essentially dead. It's currently at version 1.2, and plans for version 1.3 were abandoned in favour of developing log4j 2.0. However, it doesn't appear that 2.0 is in active development. It is worth noting that Ceki Gülcü, the original founder of the log4j project, has moved on to slf4j (see below).

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
Kartoch
  • 7,610
  • 9
  • 40
  • 68
6

Looking at the slf4j page it doesn't look like it would replace log4j - it would just allow you to use the same underlying logging framework (e.g. log4j) for your whole application, allowing libraries to hook into that automatically.

It looks more like a replacement for Apache Commons Logging than log4j.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
3

Slf4j is not a real logging facade. Slf4j does not support many features of its implementors. For short, I mention log4j examples below.

  • Slf4j cannot specify a user selected configuration file, but forces user to use default (log4j.properties or log4j.xml) at one of so many Java roots (each Jar has one root plus JVM root and classes or bin). If two JAR files have it, it is hard to control which one to use safely.
  • Slf4j cannot support all Log4j levels, such as 'fatal'. When switch big code from Log4j to Slf4j, huge code change effort is needed (e.g. deciding how to rearrange levels).
  • Two key Jar files (log4j-over-slf4j.jar or slf4j-log4j12.jar) must be chosen. If classpath both, won't work. If choose one randomly, lose unexpected features (e.g. log4j-over-slf4j.jar does not support multiple log files for same classes; e.g. one for events log and one for raw data log).
Steven S Wang
  • 31
  • 1
3

SLF4J has, in my opinion, the huge advantage that you can unify the logging of all the libraries that you use through the bridges that it provides. Neither of the other logging frameworks allows this. This allows projects to smoothly move to SLF4J and ignore the logging framework choices that dependencies have made.

Thomas Lötzer
  • 24,832
  • 16
  • 69
  • 55