[slf4j-dev] Release of SLF4J version 1.6.0-RC0

[Ceki Gülcü]

Hi All,

To emphasize the still experimental nature of 1.6.0, I made a new 
release changing suffix from RC to alpha. This will give us more wiggle 
room. More below.

On 24/04/2010 3:55 PM, Joern Huxhorn wrote:

> One of my goals in slf4j-n was to reduce the number of methods in the
> Logger interface.
> This was seemingly a bad idea since it would have a performance impact,
> in the case where a message isn't actually logged, as Ralph reported.
>
> Because of this, it would be very wise to keep all the methods that are
> already present in the Logger interface and simply add
> debug(Message)
> debug(Message, Throwable)
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> [same for other levels plus generic log(Level, ...)-methods]
>
> The designer in me doesn't like the "bloated" (in the sense that some
> methods could be dropped without losing functionality) interface, but
> the realist in me accepts that performance is more important than
> aesthetics ;)

Can't we coalesce debug(Message), debug(Message, Throwable), 
debug(Marker, Message) and debug(Marker, Message, Throwable) into a 
single variant?

Here is an idea:

try {
   ...
} catch(Throwable t) {
  Message m = new Message("hello{}").addParam("word").add(marker).add(t);
  logger.error(m);
}

This approach incurs the cost of creating and building the Message 
object regardless of whether the request will be logged or not. I 
suspect that the bulk of the cost is due to the object creation incurred 
by new Message(...) and not due to the addition of extra data incurred 
in calling addParam() and the other add() methods. Thus, 
performance-wise we are in the same position as the original Message 
proposal but now we can get rid of all the overloaded variants dealing 
with Marker and throwable.

> The big advantage, on the other hand, would be that the interfaces would
> indeed stay compile-time compatible.
>
> I only dropped this requirement since I assumed that the original
> slf4j-api was absolutely frozen (and I still think that it would be a
> good idea to keep it that way...).

> slf4j-api and slf4j-n-api were meant to exist side by side, with the
> former ensuring backwards-compatibility with Java 1.4 and slf4j-n-api
> for explicit opt-in to new functionality by changing the imports of
> Logger and LoggerFactory.

> If the preconditions of a frozen slf4j-api and Java 1.4 compatibility
> have been dropped, there's no use for a separate slf4j-n-api and we can
> simply extend the current Logger interface with the previously mentioned
> methods.

If the Logger interface was frozen, then slf4j-n-api was the only
possibility to evolve the API.

> Cheers,
> Joern.