[slf4j-user] Replaceable MessageFormatter

[Joachim Durchholz]

Am 26.12.2013 23:28, schrieb Chris Pratt:
>    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())

Nah, I'm using logback for a reason.

 > or do log.debug("The file {} was created on
> {}",file.getAbsoluteFile().toString(),file.lastModified());?

This.

 > In both
> cases, you are performing computations that are thrown away in a production
> environment.

Sure. So what?
90% of the code isn't running very often anyway.
Of the 10% that are run in a tight loop and are potentially(!) 
optimization-worthy, 99% are just parameterless getters (it's 
exceedingly rare that something that's log-worthy isn't already 
available as a member field somewhere).
My observation has been that the remaining 0.1% are easily wrapped in an 
if() statement.

BTW Java wraps the variable parameter list in an array, which is an 
overhead that should dwarf that of inlineable simple getters. What takes 
the time is the string concatenation, not the member field accessors.

> 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);

So you're not just after getters but after a full expression language.

Which I think is a bit over the top for something that (a) rarely 
matters, (b) is already deep in the area of diminishing returns, (c) has 
a workaround, (d) will become irrelevant with closures, and (e) causes 
lots of untested executable strings until they are actually executed.

Sure, you seem to have a readymade solution so the problems wouldn't 
affect anybody except those using your lib.
But it's the opposite of KISS. And logging should follow that principle, 
simply because if logging fails you're in deep trouble because you lose 
your diagnostics.

I'm using a fairly complicated logback appender, which did run into 
failure and which I'm pretty unhappy about. But at least I can specify 
alternate, more primitive and hence more robust appenders. The formatter 
is on a code path that constitutes a single point of failure; have a bug 
in the format string and the message will never be emitted.
You could work around that by catching exceptions and emitting the raw 
format string and appending the parameter values, but (1) the parameter 
values won't help much because you're after details from their innards, 
and (2) the exception should be logged but you can't log from inside 
logging code, SLF4J will drop such log messages to prevent endless 
recursion.