Log4j2 — Is it worth to use Slf4j with log4j2 ?
It’s safe: the Log4j2 API offers the exact same guarantees as slf4j — and more.
Now that Log4j2 itself is separated into an API and an implementation module, there is no longer any value in using SLF4J.
Yes, it is good engineering practice to keep your options open. You may want to change to another logging implementation later.
For the last 10 years or so, building such flexibility in your application meant using a wrapper API like SLF4J. This flexibility doesn’t come for free though: the disadvantage of this approach is that your application cannot use the richer feature set of the underlying logging library.
Log4j2 offers a solution that doesn’t require that your application is restricted to the lowest common denominator.
The escape valve: log4j-to-slf4j
Log4j2 includes a log4j-to-slf4j bridge module. Any application coded against the Log4j2 API can choose to switch the backing implementation to any slf4j-compliant implementation at any time.
As mentioned in the question, using the Log4j2 API directly offers more functionality and has some non-functional advantages versus using a wrapper API like slf4j:
- Message API
- Lambdas for lazy logging
- Log any Object instead of just Strings
- Garbage-free: avoid creating varargs or creating Strings where possible
- CloseableThreadContext automatically removes items from the MDC when you’re finished with them
(See 10 Log4j2 API features not available in SLF4J for more details.)
Applications can safely use these rich features of the Log4j2 API without being locked in to the native Log4j2 core implementation.
SLF4J is still your safety valve, it just doesn’t mean your application should code against the SLF4J API anymore.
Disclosure: I contribute to Log4j2.
Update: There seems to be some confusion that programming to the Log4j2 API somehow introduces a “facade for a facade”. There is no difference in this respect between the Log4j2 API and SLF4J.
Both APIs require 2 dependencies when using a native implementation, and 4 dependencies for a non-native implementation. SLF4J and the Log4j2 API are identical in this respect. For example:
The bottom line
If you want the features afforded by Log4J2 then go for them. If you don’t need them, SLF4J is a mature, stable interface with a lot of support. SLF4J remains an important piece of the open-source infrastructure. Ceki has done the community a great service, for a lot of griping in return.
But rich APIs supported by competent implementations prevail in the end. Today’s stability is tomorrows stagnation. The process of refinement keeps going. No need to get off the bus so long as it is going where you want to go.
That’s all for now. Thanks!
