SLF4J is a simple facade API, where we can plug-in the desired logging implementation system at deployment time. Specially in a scenario where you are writing a library and don't want the users of that library to tie to a particular logging implementation, you should use SLF4J.
SLF4J vs JCL
SLF4J is similar to JCL but claims to fix many issues of JCL (specially class loading issues). JCL uses a runtime discovery mechanism to find a logging implementation, whereas, SLF4J uses more straight forward binding mechanism (see next).
SLF4J bindings
Along with SLF4J API jar and a logging implementation jar, we need to provide a binding jar. For example slf4j-log4j12-1.8.0-alpha2.jar binds SLF4J to Log4j framework.
This binding is based on java.util.ServiceLoader#load() which loads org.slf4j.spi.SLF4JServiceProvider implementations in the classpath.
A specific SLF4JServiceProvider implementation (e.g. Log4j12ServiceProvider provided in slf4j-log4j12-1.8.0-alpha2.jar) redirects the log messages from SLF4J API to underlying logging framework implementation.
SLF4J expects only one implementation of SLF4JServiceProvider in the classpath, if there are multiple implementations then it gives a hard warning and then uses the first one. More info.
Before Version 1.8.0, SLF4J used a more static approach for loading an implementation. From faq:
In version 1.8.0, SLF4J has been modularized per JPMS/Jigsaw specification. Moreover, slf4j-api now relies on the ServiceLoader mechanism to find its logging backend. Earlier versions relied on the static binder mechanism which is no longer honored by slf4j-api version 1.8.x. More specifically, when initializing the LoggerFactory class will no longer search for the StaticLoggerBinder class on the class path.
Also note that, if you are using maven then the dependency of binding jar (e.g. slf4j-log4j12-1.8.0-alpha2.jar) alone is good enough to be declared as it will also transitively pull slf4j-api jar and the implementation jar.
Fail-fast
Due to the way that classes are loaded by the JVM, the SLF4J binding will be verified automatically very early on. If SLF4J cannot find a binding on the class path it will emit a single warning message and default to no-operation implementation.
SLF4J provides backward compatibility between the different versions of API jars. The different versions of API and 'the binding' jars are not compatible though. Check out this.
Relation with Logback
Logback is another logging implementation which natively uses SLF4J API.
Bridging Legacy APIs
The 'JCL over SLF4J' bridge, i.e jcl-over-slf4j.jar, can redirect the logging calls from JCL to SLF4J. This is useful when some part of your application or third party library uses JCL which possibly cannot be migrated to SLF4J.
Similarly, log4j-over-slf4j.jar and jul-to-slf4j modules will allow you to redirect log4j and java.util.logging calls to SLF4J. More info.
SLF4J Migrator
A GUI application which can be used to migrate the source code files from JCL to SLF4J API. More info.
