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 <c...@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@qos.ch > http://mailman.qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-dev
