[slf4j-dev] Proposal for SLF4J 2.0 Logger API

[Remko Popma]

Hi Ceki,

Sorry for raising this via the wrong channel initially.

If there is still time for SLF4J 2.0, I propose changing the Logger methods
that take a String to accept an Object instead (excl. the methods that take
format params); this enables various use cases and optimizations in SLF4J
implementations that are not possible with the String-based API.

One potential use case is a garbage-free implementations of the API. A
Logger implementation could check if the specified Object implements
java.lang.CharSequence, for example, and extract the message text without
allocating a temp String object. GC-sensitive apps could then log
StringBuilder objects, for example.

Another use case is binary logging; if the logging implementation has an
efficient way to map domain objects to a binary representation (as opposed
to a textual representation), then this could be both faster and produce
more compact output, which may be of interest to a certain type of
applications. The binary presentation could be converted back to text
offline or on-demand. Such use cases are not possible if the SLF4J API only
provides methods that accept Strings: information has been lost by the time
the logging implementation is invoked.

I cannot think of any downside, only upside, of replacing methods like
Logger.info(String) with Logger.info(Object) in the API. For API users this
would be a backwards compatible change.

API implementations would need to do something extra to get the textual
representation from the specified Object, but not much - this could be as
simple as calling toString on it.

However, an Object-based API opens the door for various use cases and
optimizations in SLF4J implementations that are otherwise not possible, as
suggested above. I'm hoping that the 2.0 major release would be an
opportunity for such changes...

Thoughts?

Remko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-dev/attachments/20191217/e2fdf279/attachment.html>