[slf4j-dev] Proposal for SLF4J 2.0 Logger API

[Gary Gregory]

One downside to logging Objects is that the logging library needs to watch
out for recursion. IOW, invoking an object's toString() may end up doing
some logging itself.

Gary

On Tue, Dec 17, 2019 at 2:36 PM Ceki <ceki at qos.ch> wrote:

> Hi Remko,
>
> Response inline.
>
> On 17.12.2019 11:51, Remko Popma wrote:
> > Hi Ceki,
> >
> > Sorry for raising this via the wrong channel initially.
>
> No problem at all.
>
> > 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.
>
> Yes, there is still time to make changes.
>
> > 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.
>
> Can you give a minimal example? String implements CharSequence. Do you
> mean another implementation of CharSquence like StringBuilder? What
> would you do with the StringBuilder passed by the user? Or maybe the
> StringBuilder is provided by the logging back-end and only borrowed by
> the client?
>
> Anyway, a minimal example would be helpful.
>
> > 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.
>
> Binary logging does not make sense to me. Anyway, if that is OK with
> you, let us not dwell on binary logging and see if the CharSequence case
> can stand on its own legs.
>
> > 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.
>
> Source code compatibility is obviously would not be an issue. However, I
> am not 100% sure if changing the input types from String to Object does
> not break the client binary. Anyway, there is another solution where a
> default implementation of Logger.info(CharSequence) is added to the
> Logger interface.
>
> > 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...
>
> Depending on the vantage point, a user might have different requirements
> from the logging API. Thus all suggestions are welcome.
> > Thoughts?
> >
> > Remko.
> >
> --
> Ceki Gülcü
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-dev/attachments/20191217/d2b6be6f/attachment.html>