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 <c...@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@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
