[slf4j-dev] Plan for SLF4J 2.0

[Joern Huxhorn]

On 08.03.2010, at 15:34, Ceki Gülcü wrote:

> On 08/03/2010 2:49 PM, Joern Huxhorn wrote:
>>
>> That's not entirely true.
>> As you stated in that comment, compatibility is not the case if  
>> someone
>> compiles against SLF4J v2 (with varargs) but the container uses JDK  
>> 1.4.
>> http://bugzilla.slf4j.org/show_bug.cgi?id=31#c75
>> I fear that SLF4J v2 might sneak up on some people by either not  
>> RTFM of
>> SLF4J v2 or by some dependency where the developers did not RTFM the
>> SLF4J v2 manual.
>> It wouldn't be our fault in both cases but it would boil down to
>> "Updating xyz broke my build" subjects in mailinglists with the
>> explanation that it was because of the SLF4J dependency.
>
> But that's OK isn't it? If project A is built under JDK 1.4, upgrading
> to SLF4J v2 would result in an incompatible class version during the
> build and the developer will be forced to stay with slf4j 1.5.x, which
> is OK.
>
> Moreover, while a container may be built using JDK 1.4 I don't see how
> a container could force the use of JDK 1.4. The end-user can always
> chose to use a later version of the JDK.
>
> My comment was about a container exporting its version of SLF4J to the
> application, but as long as SLF4J v1 and v2 are binary compatible that
> would not be a problem. If v1 and v2 are NOT binary compatible, then  
> that's
> a different matter altogether.

It's just that AFAIK Websphere requires a certain JRE.
I've no personal experience with it, though (thankfully!)...

>>
>> Lots of people switched their codebase over to SLF4J by a simple  
>> search
>> & destroy, I guess.
>
> Search and replace, not destroy. :-)

Yes, indeed ;)

>
>>>
>>>> It's a shame that there's no tool to analyze the whole central  
>>>> Maven2
>>>> repository concerning this, or is there?
>>>> It would be great if there was a way to find out which modules  
>>>> depend on
>>>> SLF4J (either directly or transitively) and are still 1.4.
>>>
>>> Let's google it. :-)
>>
>> Did you succeed?
>
> No, that's was my feeble attepmt at cracking a joke.

There goes my hope ;)

>
>>> If we are going to re-implement org.slf4j.Logger under
>>> org.slf4j.n.Logger, we might as well call it org.newslf4j.Logger and
>>> start over from scratch. Copying the API to new packages avoids
>>> conflicts but otherwise constitutes a radical break.
>>
>> Yes, it does. But it also cleans up the API and adds some very
>> substantial features.
>>
>> There are lots of methods that aren't necessary anymore with  
>> varargs and
>> exception support built in.
>>
>> Additional ones would be extremely nice to have.
>> Methods supporting the (or a) Message interface would enable the  
>> user to
>> define his own application-specific message implementation which  
>> would
>> bring a whole new level to the framework. He could access those  
>> special
>> messages without parsing in specifically written appenders.
>>
>> I've also added log(Level,....) and isEnabled(Level[,Marker])-methods
>> for cases where the actual level a call uses is determined
>> programmatically.
>> This is something that we needed on several occasions, too.
>>
>> But additional methods can't be added to the original SLF4J  
>> because, as
>> you correctly enforce, SLF4J API is frozen and must stay that way.
>>
>> What I suggest is a bit like the junit package switch. With JUnit 4  
>> the
>> package changed from junit to org.junit. The original junit keeps
>> working as before but new stuff was added in org.junit.
>
> Good point. There are several differences between the Junit case and  
> SLF4J. Junit3 had maybe 99% market share of the unit testing API  
> "market". The market shared being eroded by TestNG which brought in  
> annotations as significant improvement over Junit3. I don't think  
> Junit4 would exist without TestNG competitive pressure.
>
> As far as I know, SLF4J has no competition from a "feature" point of  
> view. Of course, there is JCL, jul and log4j but they all have less  
> advanced user-facing logging APIs.

I can't argue against this, there's no real competitive pressure right  
now.

On the other hand, I think that this is somewhat caused by the fact  
that you are developing both SLF4J and Logback (which is IMHO the  
state of the art concerning logging) - meaning that there won't be  
pressure from that side.

Concerning features, JUL supports logging for a given level, e.g.  
log(Level level, String msg).
With SLF4J one has to (re)invent a level  incl. code like
switch(level)
{
case DEBUG: logger.debug(...);
break;
[... etc.]
}

Instead of waiting for competition to appear (e.g. Log4J 2.0?), we  
should innovate anyway.

>
>> You are right: the package could be named anything.
>>
>> The only reasons I choose org.slf4j.n was
>> a) making a switch easy by just adding .n to import statements
>> b) using the SLF4J brand because it's established and people already
>> believe/put trust in it
>> c) it was merely a suggestion
>>
>> The main point, though, is, that there would be zero impact on any
>> existing code base. Everything, even SLF4J implementations, don't  
>> have
>> to do anything. The new API would be supported anyway.
>>
>> In case of JDK>=1.5 implementations like Logback, it does make a  
>> lot of
>> sense to implement the new API directly (so the Message reaches the
>> appenders - instead of an String) and wrapping the other way around,
>> i.e. using a wrapper to support the original SLF4J API (which is  
>> already
>> provided in the new Logger interface via getOldLogger() method). But
>> this isn't required for org.slf4j.n to work.
>
> IMO, support for messages can be sufficiently important as to  
> justify a
> new API but I am not convinced yet.
>

What would it take to convince you?

The addition of Message support would solve problems like the  
following in an unintrusive
http://bugzilla.slf4j.org/show_bug.cgi?id=116 (java.util.Formatter  
support)
http://bugzilla.slf4j.org/show_bug.cgi?id=148 (StructuredData support,  
RFC 5424)
http://jira.qos.ch/browse/LBCLASSIC-76 (Allow extension of  
LoggingEvent with new data)

Also, the Message instance might be used in Logback TurboFilters, I  
think.
It may be necessary to change the interface (or at least the  
implementation of ParameterizedMessage) a bit for better performance,  
i.e. deferring the evaluation (searching for Throwable) and  
transformation of the argument[] into a String[] until after the  
TurboFilter. (Yes, I know, that's a Logback-only issue)

> By the way, the invitation made to Juergen regarding a link at a
> prominent place on the SLF4J web-site extends to your fork as
> well. I'll gladly add a link to
> http://github.com/huxi/slf4j/tree/slf4j-redesign with a description
> provided by you so that can people can try it out and provide
> feedback.
>
> WDYT?

I'd have no problem with that, though I'm not sure if I'll be able to  
keep that branch updated with the main SLF4J branch.
The main problem I see is that it's not worth that much without  
Logback supporting it. It's nice to have the Messages but a lot of  
power is lost if the appenders in Logback are still getting an event  
containing a formatted message string. Ralph couldn't use the  
StructuredData without parsing it first, for example.

Cheers,
Joern.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20100309/3ce348ea/attachment-0001.html>