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?

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

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?