Am 26.12.2013 20:46, schrieb Chris Pratt:
You recognized that constructing a string to be thrown away when it was determined the logging level was insufficient was inefficient, which is totally true, but it fails to take into consideration that just accessing and formatting the data for display can be quite costly as well. I would propose to extend the already existing replacement parameters, giving them the ability to be positionally referenced, dot notated, and format specified to prevent retrieving and formatting data before it's known that the data is necessary.
FWIW, this has been happening so rarely for me that I do not consider the occasional if(logger.isDebugEnabled()) block burdensome.
There's also the question of how much does one want in the format: The maximal solution would be an interpreter for something Turing-complete in the format, which is obviously way over the top, the minimal solution would be what we're having now: just substitute in expressions. Some decision should be made at what point between these extremes SLF4J should lie, otherwise, adding a formatter here and extending it there will end with evil feature creep. (If there are too many formatters of that kind around, there's also the burden of deciding which formatter to use, making SLF4J more complicated to use; it's not a long-term concern, but it would raise the entry barrier.)
Finally, I think Java 8's closures will make the entire point moot. Make the SLF4J logging functions accept a String-returning closure, and specify whatever computations you want inside the parameter - it won't be evaluated until SLF4J actually runs it.
Of course, not everybody can postpone such issues to Java 8. Just my 2 cents on that topic. Back to lurking mode :-) _______________________________________________ slf4j-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/slf4j-user
