I have seen this question but does not answer me.

It have a brand new project. I have almost always used Log4J but now I am seeing SLF4J making some waves. What is it that Log4J could not do and we needed SLF4J? Is it really an upgrade. Should I use it in a project which will also have an API for other to extend upon?

3 Answers 3


SLF4J is basically an abstraction layer. It is not a logging implementation. It means that if you're writing a library and you use SLF4J, you can give that library to someone else to use and they can choose which logging implementation to use with SLF4J e.g. log4j or the Java logging API. It helps prevent projects from being dependent on lots of logging APIs just because they use libraries that are dependent on them.

So, to summarise: SLF4J does not replace log4j, they work together. It removes the dependency on log4j from your library/app.

Take a look here: http://www.slf4j.org/, or even here: http://commons.apache.org/logging/ (Apache Commons Logging is similar to SLF4J) for more info on this concept.


slf4j is an API designed to give generic access to many logging frameworks and then with a lot of glue code allowing existing code to be used easily. Which one you use, is then decided at deployment time, not when you write your code.

Best practice today is to use slf4j to for your own log statements, and then choose the appropriate backend for it. Here log4j.

The primary reason for migrating is that you get {} in your message strings allowing you to skip the ifDebug() { log("...") } construct.


As said SLF4j is only a logging API/interface, it does not directly replace log4j which is a complete logging framework (with configurable appenders, filters, …) but replaces Commons Logging as a framework-agnostic API for logging.

SLF4j can be configured to use log4j as a logging backend so they can work together. However a quite closely related project is logback (http://logback.qos.ch/). Logback is a replacement for Log4j: it is a logging framework (as Log4j) but it uses natively the SLF4j API.

SLF4j has some useful companion JAR files which can be used to make other logging API delegate to the SLF4j API : jcl-over-slf4j (replacement API compatible with commons logging), jul-to-slf4j (for java.util.logging), log4j-over-slf4j (API compatible with log4j). Using those you can have a lot of logging API talk forward to SLF4j (useful for third-party JARs) so that you have a single logging framework handling all logs.

The SLF4j API supports the "MDC" feature of log4j/logback (which is not availablog in the Commons Logging API) so you can use this feature in your project without depending on a specific framework. You probably can replace log4j calls with SLF4j calls in your code (unless your using other features such as NDC) but you will probably still want to ship log4j or slf4j as a backend for the SLF4j API.

Not the answer you're looking for? Browse other questions tagged or ask your own question.