Introduction to SLF4J

1. Overview

Simple Logging Facade for Java (abbreviated SLF4J) acts as a facade for different logging frameworks (e.g., java.util.logging, logback, Log4j). It offers a generic API, making the logging independent of the actual implementation.

This allows for different logging frameworks to coexist. And it helps migrate from one framework to another. Finally, apart from standardized API, it also offers some “syntactic sugar.”

This tutorial will discuss the dependencies and configuration needed to integrate SLF4J with Log4j, Logback, Log4j 2, and Jakarta Commons Logging.

For more information on each of these implementations, check out our article Introduction to Java Logging.

2. The Log4j 2 Setup

To use SLF4J with Log4j 2, we add the following libraries to pom.xml:

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
    <version>2.23.1</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.23.1</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-slf4j2-impl</artifactId>
    <version>2.23.1</version>
</dependency>

The latest version can be found here: log4j-api, log4j-core, log4j-slf4j-impl.

The actual logging configuration adheres to the native Log4j 2 configuration.

Let’s see how to create the Logger instance:

public class Slf4jExample {

    private static Logger logger = LoggerFactory.getLogger(Slf4jExample.class);

    public static void main(String[] args) {
        logger.debug("Debug log message");
        logger.info("Info log message");
        logger.error("Error log message");
    }
}

Note that the Logger and LoggerFactory belong to the org.slf4j package.

An example of a project running with this configuration is available here.

3. The Logback Setup

We don’t need to add SLF4J to our classpath to use it with Logback since Logback is already using SLF4J. It’s the reference implementation.

So, we just need to include the Logback library:

<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>1.2.6</version>
</dependency>

The latest version can be found here: logback-classic.

The configuration is Logback-specific but works seamlessly with SLF4J. With the proper dependencies and configuration in place, we can use the same code from previous sections to handle the logging.

4. The Log4j Setup

In the previous sections, we covered a use case where SLF4J “sits” on top of the particular logging implementation. Used like this, it completely abstracts away the underlying framework.

There are cases when we cannot replace the existing logging solution e.g., due to third-party requirements. But this does not restrict the project to only the already used framework.

We can configure SLF4J as a bridge and redirect the calls to an existing framework to it.

Let’s add the necessary dependencies to create a bridge for Log4j:

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>log4j-over-slf4j</artifactId>
    <version>1.7.30</version>
</dependency>

With the dependency in place (check for the latest at log4j-over-slf4j), all the calls to Log4j will be redirected to SLF4J.

Take a look at the official documentation to learn more about bridging existing frameworks.

Just as with the other frameworks, Log4j can serve as an underlying implementation.

Let’s add the necessary dependencies:

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-log4j12</artifactId>
    <version>1.7.30</version>
</dependency>
<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.17</version>
</dependency>

Here are the latest versions for slf4j-log4j12 and log4j. An example project configured this way is available here.

5. JCL Bridge Setup

In the previous sections, we showed how to use the same codebase to support logging using different implementations. While this is the main promise and strength of SLF4J, it is also the goal behind JCL (Jakarta Commons Logging or Apache Commons Logging).

JCL is intended as a framework similar to SLF4J. The major difference is that JCL resolves the underlying implementation during runtime through a class-loading system. This approach can seem problematic in cases where there are custom class loaders at play.

SLF4J resolves its bindings at compile time. It’s perceived as simpler yet powerful enough.

Luckily, two frameworks can work together in the bridge mode:

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>jcl-over-slf4j</artifactId>
    <version>1.7.30</version>
</dependency>

The latest dependency version can be found here: jcl-over-slf4j.

As with the other cases, the same codebase will run just fine.

6. Further SLF4J Features

SLF4J provides additional features that can make logging more efficient and code more readable.

For example, SLF4J provides a very useful interface for working with parameters:

String variable = "Hello John";
logger.debug("Printing variable value: {}", variable);

Here is the Log4j code doing the same thing:

String variable = "Hello John";
logger.debug("Printing variable value: " + variable);

As we can see, Log4j will concatenate Strings whether the debug level is enabled or not. In high-load applications, this may cause performance issues. On the other hand, SLF4J will concatenate Strings only when the debug level is enabled.

To do the same with Log4J, we need to add an extra if block, which will check if the debug level is enabled:

String variable = "Hello John";
if (logger.isDebugEnabled()) {
    logger.debug("Printing variable value: " + variable);
}

SLF4J standardized the logging levels, which are different for the particular implementations. It drops the FATAL logging level (introduced in Log4j) based on the premise that in a logging framework, we should not decide when to terminate an application.

The logging levels used are ERROR, WARN, INFO, DEBUG, and TRACE. Read more about using them in our Introduction to Java Logging.

7. Conclusion

SLF4J helps with the silent switching between logging frameworks. It is simple, yet flexible, and allows for readability and performance improvements.