|The Java Logging Battleground Gets Two New Updates|
|Written by Nikos Vaggalis|
|Thursday, 13 October 2022|
New releases of two popular APIs update Java's logging battleground. Battleground because there are two front runners. The two APIs in question are SLF4J 2.0.0 and Log4j 2.19.0.
First of all, let's meet them both. SLF4J stands for Simple Logging Facade for Java and is an interface for various logging backend frameworks like java.util.logging, logback, log4j and log4j2 so that applications can use any of them interchangeably without changing code.
However, despite SLF4J's portability and in order to work with it, each backend framework requires a specific config file, something that has raised question of whether SLF4J is actually that useful; if that is the case why not just go straight for an implementation like log4j directly, forgoing SLF4J completely? It's a valid argument, but the real value of SLF4J is for people producing libraries and you don't want to force a specific logging framework onto your clients. The SLF4J abstraction allows the consumer to choose an implementation.
SLF4J's 2. 0. x series major improvement is the addition of a backward-compatible fluent logging api. The idea is to build a logging event piece by piece with a LoggingEventBuilder and to log once the event is fully built. The methods atTrace(), atDebug(), atInfo(), atWarn() atError(), all new in the org.slf4j.Logger interface, return an instance of LoggingEventBuilder.
Here are few usage examples:
is equivalent to:
The following log statements are equivalent in their output (for the default implementation):
For most users, upgrading to version 2. 0. x should be a drop-in replacement, as long as the logging provider is updated as well. Existing frameworks must migrate to the ServiceLoader mechanism since slf4j-api now relies on this to find its logging backend.
What are those existing frameworks if SLF4J is an abstraction over them?
That said, Log4j2 has a new version 2.19.0 as of this September, primarily containing bug fixes and minor enhancements. As discussed, it also needed to change to support the new SLF4J 2.0.x ServiceLoader mechanism:
Due to breaks in compatibility in the SLF4J binding, Log4j now ships with two versions of the SLF4J to Log4j adapters. log4j-slf4j-impl should be used with SLF4J 1. 7. x and earlier and log4j-slf4j2-impl should be used with SLF4J 2. x and later. SLF4J-1. 8. x is no longer supported as a GA release never occurred.
Apache Log4j 2.19.0, as well as SLF4J 2. 0. x, requires a minimum of Java 8 to build and run.
Finally, note that Log4j2 also provides an API for various logging implementations like SLF4J does. In that sense it competes with SLF4J since it acts both as a facade and an implementation.
As such, the Log4j API is a logging facade that may, of course, be used with the Log4j implementation, but may also be used in front of other logging implementations such as Logback. The Log4j API has several advantages over SLF4J:
Log4j 2 does a lot, but that's both a blessing and a curse as the latest Log4JShell vulnerability demonstrated. Trying to go overboard by allowing any inputs to be parsed and interpreted by the application, no matter where it originates, just for providing more functionality to its users, opened it wide to exploits.
|Last Updated ( Thursday, 13 October 2022 )|