Introduction

slf4j-simple is the minimal SLF4J binding for applications that just need straightforward console logging. It is useful for small services, utilities, tests, and demos where a full logging framework would be unnecessary overhead. The important part of configuring it is understanding that you are selecting one SLF4J backend and controlling it mostly through system properties or a simplelogger.properties file.

Add Exactly One SLF4J Binding

Start by depending on slf4j-api and slf4j-simple together.

1dependencies {
2    implementation 'org.slf4j:slf4j-api:2.0.13'
3    runtimeOnly 'org.slf4j:slf4j-simple:2.0.13'
4}

For Maven, the same idea applies.

1<dependencies>
2  <dependency>
3    <groupId>org.slf4j</groupId>
4    <artifactId>slf4j-api</artifactId>
5    <version>2.0.13</version>
6  </dependency>
7  <dependency>
8    <groupId>org.slf4j</groupId>
9    <artifactId>slf4j-simple</artifactId>
10    <version>2.0.13</version>
11    <scope>runtime</scope>
12  </dependency>
13</dependencies>

Only one binding should be active at runtime. If you also pull in Logback or another SLF4J backend, SLF4J will warn about multiple bindings and your logging setup becomes ambiguous.

Configure with simplelogger.properties

A common approach is putting a simplelogger.properties file on the runtime classpath.

1org.slf4j.simpleLogger.defaultLogLevel=info
2org.slf4j.simpleLogger.showDateTime=true
3org.slf4j.simpleLogger.dateTimeFormat=yyyy-MM-dd HH:mm:ss.SSS
4org.slf4j.simpleLogger.showThreadName=true
5org.slf4j.simpleLogger.showLogName=false
6org.slf4j.simpleLogger.showShortLogName=true
7org.slf4j.simpleLogger.log.com.example=debug

Place that file in src/main/resources so it is included in the built artifact. This gives you one central logging policy for the application.

System Properties Also Work Well

For command-line tools or temporary overrides, configuration through JVM system properties is often more practical.

1java \
2  -Dorg.slf4j.simpleLogger.defaultLogLevel=debug \
3  -Dorg.slf4j.simpleLogger.showDateTime=true \
4  -jar app.jar

This is useful in CI jobs or local debugging sessions because you can change logging without rebuilding the application or editing packaged resources.

Use SLF4J Normally in Code

Once the binding is present, application code uses the standard SLF4J API.

1import org.slf4j.Logger;
2import org.slf4j.LoggerFactory;
3
4public class MyApp {
5    private static final Logger log = LoggerFactory.getLogger(MyApp.class);
6
7    public static void main(String[] args) {
8        log.info("Application starting");
9        log.debug("Debug details enabled");
10        log.error("Example error message");
11    }
12}

That is the point of SLF4J: the code stays written against the facade, while the runtime chooses the backend.

Know What slf4j-simple Is Good At

slf4j-simple is intentionally limited. It is a good fit when you want:

• one lightweight backend
• console output
• basic level control
• minimal setup

It is not the right choice if you need rolling files, structured appenders, asynchronous logging, or complex routing. In those cases, use a richer backend such as Logback.

The configuration question is therefore partly architectural. slf4j-simple is simple because it omits advanced features, not because those features are hidden somewhere in a more complicated config file. That tradeoff is often a feature in command-line tools and tests, where fewer moving parts make troubleshooting easier.

Keep Package-Level Overrides Targeted

Per-package log levels are helpful, but use them narrowly. Turning an entire dependency tree to debug can bury the signal in noise.

org.slf4j.simpleLogger.log.com.example.payment=debug
org.slf4j.simpleLogger.log.org.hibernate=warn

That sort of targeted override is more sustainable than one global debug setting for everything.

Common Pitfalls

• Including multiple SLF4J bindings and ignoring the startup warnings.
• Expecting slf4j-simple to support advanced features such as rolling files or complex appenders.
• Placing simplelogger.properties somewhere that is not actually on the runtime classpath.
• Using only global log levels and then drowning in noise from dependencies.
• Writing code against a concrete logger implementation instead of the SLF4J API.

Summary

• Add slf4j-api plus exactly one runtime binding, in this case slf4j-simple.
• Configure it through simplelogger.properties or JVM system properties.
• Keep application code on the SLF4J facade, not a concrete backend API.
• Use package-level overrides when you need focused debugging.
• Choose slf4j-simple only when lightweight console logging is genuinely enough.