<div><div dir="auto">Hi Ceki, sorry, I caught a stomach bug. Give me a day or so to reply properly. -Remko</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 18, 2019 at 4:36 Ceki <<a href="mailto:ceki@qos.ch">ceki@qos.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Remko,<br>
<br>
Response inline.<br>
<br>
On 17.12.2019 11:51, Remko Popma wrote:<br>
> Hi Ceki,<br>
> <br>
> Sorry for raising this via the wrong channel initially.<br>
<br>
No problem at all.<br>
<br>
> If there is still time for SLF4J 2.0, I propose changing the Logger <br>
> methods that take a String to accept an Object instead (excl. the <br>
> methods that take format params); this enables various use cases and <br>
> optimizations in SLF4J implementations that are not possible with the <br>
> String-based API.<br>
<br>
Yes, there is still time to make changes.<br>
<br>
> One potential use case is a garbage-free implementations of the API. A <br>
> Logger implementation could check if the specified Object implements <br>
> java.lang.CharSequence, for example, and extract the message text <br>
> without allocating a temp String object. GC-sensitive apps could then <br>
> log StringBuilder objects, for example.<br>
<br>
Can you give a minimal example? String implements CharSequence. Do you <br>
mean another implementation of CharSquence like StringBuilder? What <br>
would you do with the StringBuilder passed by the user? Or maybe the <br>
StringBuilder is provided by the logging back-end and only borrowed by <br>
the client?<br>
<br>
Anyway, a minimal example would be helpful.<br>
<br>
> Another use case is binary logging; if the logging implementation has an <br>
> efficient way to map domain objects to a binary representation (as <br>
> opposed to a textual representation), then this could be both faster and <br>
> produce more compact output, which may be of interest to a certain type <br>
> of applications. The binary presentation could be converted back to text <br>
> offline or on-demand. Such use cases are not possible if the SLF4J API <br>
> only provides methods that accept Strings: information has been lost by <br>
> the time the logging implementation is invoked.<br>
<br>
Binary logging does not make sense to me. Anyway, if that is OK with <br>
you, let us not dwell on binary logging and see if the CharSequence case <br>
can stand on its own legs.<br>
<br>
> I cannot think of any downside, only upside, of replacing methods like <br>
> Logger.info(String) with Logger.info(Object) in the API. For API users <br>
> this would be a backwards compatible change.<br>
<br>
Source code compatibility is obviously would not be an issue. However, I <br>
am not 100% sure if changing the input types from String to Object does <br>
not break the client binary. Anyway, there is another solution where a <br>
default implementation of Logger.info(CharSequence) is added to the <br>
Logger interface.<br>
<br>
> API implementations would need to do something extra to get the textual <br>
> representation from the specified Object, but not much - this could be <br>
> as simple as calling toString on it.<br>
> <br>
> However, an Object-based API opens the door for various use cases and <br>
> optimizations in SLF4J implementations that are otherwise not possible, <br>
> as suggested above. I'm hoping that the 2.0 major release would be an <br>
> opportunity for such changes...<br>
<br>
Depending on the vantage point, a user might have different requirements <br>
from the logging API. Thus all suggestions are welcome.<br>
> Thoughts?<br>
> <br>
> Remko.<br>
> <br>
--<br>
Ceki Gülcü<br>
_______________________________________________<br>
slf4j-dev mailing list<br>
<a href="mailto:slf4j-dev@qos.ch" target="_blank">slf4j-dev@qos.ch</a><br>
<a href="http://mailman.qos.ch/mailman/listinfo/slf4j-dev" rel="noreferrer" target="_blank">http://mailman.qos.ch/mailman/listinfo/slf4j-dev</a></blockquote></div></div>