Is Log4j being abandoned in favor of Slf4j?

Question

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?

This is my first question here, so please be gentle

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.

• More classloading issues by log4j: http://articles.qos.ch/classloader.html

Answer 1

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.

Answer 2

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.

Answer 3

Slf4J is not an alternative for Log4j, but rather provides a Facade 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)

Answer 4

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).

Answer 5

Slf4j is indeed just a logging facade. However, Log4j is intented 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?