<div dir="ltr">Joachim,<div><br></div><div>  I'm not sure what you are saying is "happening so rarely" for you??  Are you saying you log information so infrequently that you rarely either do log.debug("The file " + file.getAbsoluteFile().toString() + " was created on " + file.lastModified()) or do log.debug("The file {} was created on {}",file.getAbsoluteFile().toString(),file.lastModified());?  In both cases, you are performing computations that are thrown away in a production environment.<div>

<br></div><div>Ceki had a valid point that replaceable loggers would be a bad idea, so I'm no longer proposing that.  My proposal would be for a single, more powerful, formatter that could handle something like log.debug("The file {0.absoluteFile} was created on {0.lastModified,date,yyyy-MM-dd",file);</div>

<div>  (*Chris*)</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 26, 2013 at 2:11 PM, Joachim Durchholz <span dir="ltr"><<a href="mailto:jo@durchholz.org" target="_blank">jo@durchholz.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 26.12.2013 20:46, schrieb Chris Pratt:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You recognized that<br>
constructing a string to be thrown away when it was determined the logging<br>
level was insufficient was inefficient, which is totally true, but it fails<br>
to take into consideration that just accessing and formatting the data for<br>
display can be quite costly as well.  I would propose to extend the already<br>
existing replacement parameters, giving them the ability to be positionally<br>
referenced, dot notated, and format specified to prevent retrieving and<br>
formatting data before it's known that the data is necessary.<br>
</blockquote>
<br></div>
FWIW, this has been happening so rarely for me that I do not consider the occasional if(logger.isDebugEnabled()) block burdensome.<br>
<br>
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.)<br>


<br>
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.<br>


Of course, not everybody can postpone such issues to Java 8.<br>
<br>
Just my 2 cents on that topic.<br>
Back to lurking mode :-)<div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
slf4j-user mailing list<br>
<a href="mailto:slf4j-user@qos.ch" target="_blank">slf4j-user@qos.ch</a><br>
<a href="http://mailman.qos.ch/mailman/listinfo/slf4j-user" target="_blank">http://mailman.qos.ch/mailman/<u></u>listinfo/slf4j-user</a><br>
</div></div></blockquote></div><br></div>