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

[Joern Huxhorn]

Hi guys,

On 24.04.2010, at 18:00, Ralph Goers <rgoers at apache.org> wrote:

> Adding new methods to an interface only affects implementations of  
> that interface, not clients of the interface. So backward  
> compatibility is maintained.

Yes, this is the case.
Clients compiled against the original interface will work using the  
extended one.

> This is exactly why I chose to implement the Message support the way  
> I did. Complete backward compatibility is maintained. I believe  
> Joern's implementation is a little different and has a bigger impact  
> as it provides a how new api layer instead of extending the existing  
> interface.

Indeed.
I developed it with the assumption that the Logger interface must not  
be extended under any circumstance.

>  IIRC Joern didn't go so far as to modify all the logback internals  
> where the Logback in my fork does.

Yes, I didn't touch Logback at all.
slf4j-n-api was meant as a base of further discussion. Your findings  
concerning performance invalidated my reduction of the interface, though

I have one remaining headache:
I'd really, really like to have generic methods that log with a Level  
parameter.
This would be an ideal place for an enum but we are still staying 1.4  
for now, right?
If we are not using an enum now, we won't be able to switch to an enum  
at a later time without breaking binary compatibility.
Because of that, I'd suggest to keep those generic log methods out of  
the interface until we actually switch to 1.5 altogether - even though  
I have several places where I could use that functionality very well!

Cheers & have a nice weekend,
Joern.

>
> Ralph
>
>
> On Apr 24, 2010, at 7:50 AM, Ceki Gülcü wrote:
>
>>
>> I believe(d) that adding methods to an interface impacts client code
>> using interface beyond the actual implementations of the
>> interface. This is not true in simple cases, for example when the
>> implementations change in accordance with changes in the
>> interface. Obviously, when client code uses a newly added method in  
>> an
>> interface and the interface available on the class path is older,
>> one is sure to run into problems.  I wonder if there are other
>> problematic cases.
>>
>> If my assumption about new methods impacting client code is wrong,
>> then that opens new possibilities.
>>
>> On 24/04/2010 3:55 PM, Joern Huxhorn wrote:
>>> 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.
>>> _______________________________________________
>>> slf4j-dev mailing list
>>> slf4j-dev at qos.ch
>>> http://qos.ch/mailman/listinfo/slf4j-dev
>>
>> _______________________________________________
>> slf4j-dev mailing list
>> slf4j-dev at qos.ch
>> http://qos.ch/mailman/listinfo/slf4j-dev
>
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://qos.ch/mailman/listinfo/slf4j-dev