Is it worth to use slf4j with log4j2
I am not able to decide whether to use slf4j or not with log4j2. Based on online posts, does not look like it will have any performance hit but is it really required.
Also these points rule in favor of log4j2:
- SLF4J forces your application to log Strings. The Log4j 2 API supports logging any CharSequence if you want to log text, but also supports logging any Object as is.
- The Log4j 2 API offers support for logging Message objects, Java 8 lambda expressions and garbage-free logging (it avoids creating vararg arrays and avoids creating Strings when logging CharSequence objects).
Answer
Go ahead: program to the log4j2 API instead of slf4j
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:
