[slf4j-dev] Proposal for SLF4J 2.0 Logger API

[Remko Popma]

Hi Ceki, sorry, I caught a stomach bug. Give me a day or so to reply
properly. -Remko

On Wed, Dec 18, 2019 at 4:36 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/20191218/1ecfb08a/attachment-0001.html>