[slf4j-dev] event API in SLF4J

[Ceki Gulcu]

Hi Thorsten,

The current API where one writes a single to log is not at risk. The 
event API is there to allow the construction of "complicated" events 
which we cannot cater for by adding new methods for whatever new 
parameter combinations. I agree that the discussion has little to do 
with 1.8 lambdas. I mentioned it as an example of the combinatorial problem.

For example, I think in the original SLF4J design which had methods in 
o.s.Logger supporting Markers as first argument was a not so good. An 
event API supporting Markers would have achieved the same  while also 
allowed many other combinations of parameters.

A better API would support for a single-line logging for the most common 
cases and a more complicated (event) API for the more elaborate cases. 
The current API supports the common cases but not more elaborate ones.

--
Ceki


On 1/24/2016 13:45, Thorsten Möller wrote:
> Hello all
>
> Warning: this is a rather critical reply. Don’t take it personally, please. My comments are meant to be about the subject, and only about the subject. Also, I haven’t actually read [1] and [2] (due to lack of time). Apologies if I’m missing something.
>
> Comments inlined.
>
> Thorsten
>
>
>> Am 23.01.2016 um 17:26 schrieb Ceki Gulcu <ceki at qos.ch>:
>>
>>
>> Hi all,
>>
>>
>> A few months ago, Nathan Green has made a proposal [1] to add Java 8 support to org.slf4j.Logger.
>
> Not sure what Java 8 support means here. SLF4J 1.7.x supports Java 8 in the sense that it can be *used* with Java 8. Isn’t this more about adding Java 8-specific features to SLF4J?
>
>
>> His proposal has the remarkable property of being backward compatible. Other proposals have been made since on the same subject [2].
>
> Nice. However, I don’t think that backwards compatibility is that important for this particular discussion: how to evolve the SLF4J API when moving on to Java 8? In fact, I consider it even dangerous. It might lead to the situation that the evolution of logging in Java rolled over SLF4J in a way that it died out because it became a dinosaur (and that metaphorism appeals to lightweight designs).
>
> Quite some Open Source libraries have seen their departure from Java 4/5 times into Java 8 times as a chance for a tabula rasa, combined with a major - (mostly) backwards incompatible - version upgrade. I’d rather like to see the same for SLF4J; that is, I’d like to see a SLF4J 2.x that dared to design a carefully revised modern API, taking into account features that were made available since Java 8 (such as static methods in interfaces). This is **not** to say that the current SLF4J API needs to be thrown away entirely. There are many things that should survive such an undertaking.
>
>
>> The org.slf4j.Logger interface already contains 55+ methods. Nathan's proposal adds yet new methods. A complete proposal would perhaps double or triple the number of methods to 100 or even 150.
>>
>> An alternative is to offer an event API allowing piecemeal construction of the logging event. Only when the event is fully constructed, is it offered to a Logger instance.
>>
>> Usage example
>>
>> LoggingEvent event = new LoggingEvent();
>> event.message("hello {}).parameter("world").marker(BLUE).level(DEBUG);
>>
>> EventLogger logger = someFactory.getLogger();
>> logger.log(event);
>
> How much "Java 8y“ is this? Couldn’t the same have existed already since the early days of Java; i.e., since Java 1.1, if not earlier? Sometimes, I like this fluent API style (that became popular recently), but it feels exaggerated here. Especially, when thinking about (i) performance/overhead and (ii) succinctness of code. Why create an object first, followed by a couple of methods calls and getting yet another reference to a logger, if the same can be achieved in the classic way:
>
> Logger myLogger = LoggerFactory.getLogger(…);
> myLogger.debug(BLUE, "hello {}", "world“);
>
> Succinct. Less overhead (less object creation/garbage collection, less stack frames to create/remove).
>
> The API design discussion is, at least for this message thread, seemingly more about whether semantics should be more implicit (classic API) or more explicit (semantics visible from method names). Btw, it seems to me that there is always a tradeoff: one cannot buy more explicit semantics for less overhead.
>
> Getting a reference to a logger, as well as logging something, should, in my opinion, remain one-liners. Saying it differently, the ratio between the amount of code needed to configure what, where, and when to log, and the amount of code that makes up the log message itself should ideally be less than one (Formally, let c be the amount of logging configuration code and let m be the amount of code for log messages themselves. Then, the lower c / m, the better. Clearly, this is an implicit semantics over explicit semantics approach, which I do not consider a problem for an educated programmer.)
>
> So, where is the Java 8 features discussion here? One thing that I clearly like to see is how SLF4J could take advantage of static methods on interfaces.
>
>>
>> Logback would fully support this interface but the same cannot be said of other logging frameworks. In that case there is not much use for introducing the interface in SLF4J instead of directly in logbook.
>>
>> Your comments are welcome.
>>
>> --
>> Ceki
>>
>> [1] http://mailman.qos.ch/pipermail/slf4j-dev/2015-October/004229.html
>> [2] https://github.com/qos-ch/slf4j/pull/70
>> _______________________________________________
>> slf4j-dev mailing list
>> slf4j-dev at qos.ch
>> http://mailman.qos.ch/mailman/listinfo/slf4j-dev
>
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-dev
>