Why is slf4j-api still at version 1.7

[daniel-vergien-bdr]

In testcontainers-java/core the slf4j-api is still on the 1.7.x version which is inactive . Is there a reason not to update to version 2? In the smoke tests testcontainers use version 2.
I think if one uses testcontainers in e.g. spring boot this is not an issue, since the slf4j version is than overridden by the framework. But if one uses testcontainers alone, one has to override the version by himself or stick to the old 1.7 version since else there is no logging from testontainers.

[rameshreddy-adutla]

Great question! The reason Testcontainers still ships with SLF4J 1.7.x in core is backwards compatibility. SLF4J 2.x introduced breaking changes:

1. StaticLoggerBinder removal — SLF4J 2.x uses ServiceLoader instead of StaticLoggerBinder. Libraries still relying on 1.7.x patterns would break.
2. Provider SPI — 2.x uses SLF4JServiceProvider instead of StaticLoggerBinder.
3. Fluent API — The fluent logging API (atInfo(), atDebug()) was added in 2.x.

Since Testcontainers is a library (not an application), it follows the best practice of depending on the lowest compatible version of transitive dependencies. This avoids forcing users into SLF4J 2.x if their project still uses 1.7.x bindings.

As you noted, Spring Boot and most modern frameworks bring in SLF4J 2.x via their own dependency management, so Maven/Gradle resolution picks the higher version anyway. The smoke tests use 2.x because they simulate real application environments.

There is likely a roadmap item for bumping the minimum to 2.x once 1.7.x usage drops below a threshold in the ecosystem.