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

[Joern Huxhorn]

Hi Ceki,

On 24.04.2010, at 13:44, Ceki Gülcü <ceki at qos.ch> wrote:

>
> Hi Joern,
>
> On 24/04/2010 1:55 AM, Joern Huxhorn wrote:
>> Hi Ceki,
>>
>> On 23.04.2010, at 16:18, Ceki Gülcü <ceki at qos.ch> wrote:
>>
>>> On 23/04/2010 2:14 PM, Joern Huxhorn wrote:
>>>> Didn't you change LocationAwareLogger and doesn't that mean that  
>>>> it's
>>>> not compatible with the current Logback anymore?
>>>> Or is this only relevant for wrappers like jcl-over-slf4j and you
>>>> changed all of them already?
>>>
>>>
>>> Right, LocationAwareLogger affects compatibility with logback but so
>>> does MessageFormatter changes, actually the latter in a deeper way  
>>> as
>>> it is no longer possible to compute the formatted message lazily in
>>> LoggingEvent. I must be computed eagerly in LoggingEvent's  
>>> constructor.
>>>
>>
>> Are you aware that my ParameterizedMessage supports both #70 and lazy
>> initialization?
>
> Yes, but ParameterizedMessage has to be passed as a Message to a  
> logger of type org.slf4j.n.Logger. More below.
>
>> This is possible since the placeholders are only counted during
>> creation. The actual formatting/placeholder replacement is only
>> performed when the formatted message is requested. The formatted  
>> message
>> is kept so it won't be regenerated in case of further calls.
>> It could also be enhanced to perform the toString of the arguments  
>> at a
>> later time. The Message interface could be extended by an
>> prepareForDeferredProcessing() method for that purpose.
>>
>> I agree with Ralph that this would be a good time to extend the  
>> Logger
>> interface with Message-aware methods since 1.6 will be incompatible  
>> anyway.
>
> Initially, I also thought that 1.6.0 was a good time to integrate your
> changes.
>
> Changing the Logger interface breaks compatibility with client code
> using SLF4J. Breaking compatibility at this level is different than
> breaking compatibility within SLF4J internals. For example, as long as
> the end-user places slf4j-api-1.6.0.jar and an appropriate 1.6.0
> binding on the class path, things will work fine without needing to
> compile client code or dependencies. However, if the logger interface
> was changed, then *all* client code (including all dependencies using
> SLF4J) would need to be recompiled. There is no comparison in the
> impact of changing SLF4J internals and changing client-facing
> interfaces such as org.slf4j.Logger.
>

Yes, I understand.
That's why I'd suggest to add Message-aware methods, leaving the  
existing ones untouched.

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

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.

Cheers,
Joern.