Should new projects use logback instead of log4j ?

Question

Should new projects use logback instead of log4j as a logging framework ?

Or with other words :'Is logback better than log4j (leaving the SLF4J-'feature' of logback beside)?'

Answer 1

I'm not familiar with SLF4J, and I've only taken a brief look at logback, but two things come to mind.

First, why are you excluding a tool from examination? I think it's important to keep an open mind and examine all possibilities to choose the best one.

Second, I think that in some projects one tool is a better than another tool, and the opposite might be true in a different project. I don't think that one tool is always better than another tool. There is, after all, no silver bullet.

To answer your question - Yes and no. It depends on the project, and how familiar the team is with one tool. I wouldn't say "don't use log4j" if the entire team is very comfortable with it, it meets all the needs, and logback doesn't offer anything that we need to complete the task.

Answer 2

the original log4j and logback were designed and implemented by the same guy.

several open source tools have used SLF4J. I don't see any significant deficiencies in this tool. So unless you have a lot extensions to log4j in your codebase, I would go ahead with logback.

Answer 3

I would think that your decision should come down to the same one it would if you were deciding between using log4j or Jakarta Commons Logging - are you developing a library which will be included in other applications? If so, then it doesn't seem fair to force users of your library to also use your logging library of choice.

If the answer is no, I would just go with what is simpler to add and what you are more comfortable with. Sounds like logback is just as extensible and reliable as log4j, so if you're comfortable using it, go ahead.

Answer 4

I would use slf4j for logging in all cases. This allow you to choose which actual logging backend you want to use, at deploy time instead of code time.

This has proven to be very valuable to me. It allows me to use log4j in old JVM's, and logback in 1.5+ JVM's, and also java.util.logging if needed.

Answer 5

You should use SLF4J+Logback for logging.

It provides neat features like parametrized messages and (in contrast to commons-logging) a Mapped Diagnostic Context (MDC, javadoc, documentation).

Using SLF4J makes the logging backend exchangeable in a quite elegant way.

Additionally, SLF4J supports bridging of other logging frameworks to the actual SLF4J implementation you'll be using so logging events from third party software will show up in your unified logs - with the exception of java.util.logging that can't be bridged the same way that other logging frameworks are.

Bridging jul is explained in the javadocs of SLF4JBridgeHandler.

I've had a very good experience using the SLF4J+Logback combination in several projects and LOG4J development has pretty much stalled.

SLF4J has the following remaining downsides:

• It does not support varargs to stay compatible with Java < 1.5
• It does not support using both parametrized message and an exception at the same time.
• It does not contain support for a Nested Diagnostic Context (NDC, javadoc) which LOG4J has.

Answer 6

Logback more JEE aware:
in general (from code to documentation) it’s keeping in mind containers – how multiple apps coexist, how class loaders implemented etc. Contexts for loggers, JNDI, JMX configuration included etc.

from developer prospective almost same, Logback adds Parameterized logging (no need to use if(logger.isDebugEnabled()) to avoid string concatenation overhead )

Log4j – only giant plus is old JVM support, small (IMO) NDC (Logback only MDC), some extensions. For example I wrote extension for configureAndWatch for Log4j, no such thing for Logback