[slf4j-dev] Plan for SLF4J 2.0

[Ceki Gülcü]

On 08/03/2010 2:49 PM, Joern Huxhorn wrote:
>
> On 06.03.2010, at 18:13, Ceki Gülcü wrote:
>>
>> As mentioned in comment #10 dated 2007-10-10 on bug 31, we can have
>> binary compatibility as long as
>>
>> logger.trace|debug|info|warn|error(String, Object[])
>> logger.trace|debug|info|warn|error(Marker, String, Object[])
>>
>> are changed to
>>
>> logger.trace|debug|info|warn|error(String, Object...)
>> logger.trace|debug|info|warn|error(Marker, String, Object...)
>>
>> with all the other methods remaining unchanged.
>>
>
> 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.

>> I find this BasicMDCAdapter.remove episode really puzzling. The only
>> simple explanation I see is that few SLF4J users run under JDK
>> 1.4 or more accurately the overlap of org.slf4j.MDC and JDK 1.4 use
>> corresponds to a very small number of users.
>
> You're right.
> But there's also the possibility that people are only putting values
> into MDC without ever removing them again, overwriting them instead.

Yes, that's also a possibility.

> Before I switched all my stuff to SLF4J I was using commons-logging.
> This was the case for all the projects I was involved in. CL did not
> support MDC and I think that this is one of the reasons why MDC is -
> even now - quite underused.
> Lots of people switched their codebase over to SLF4J by a simple search
> & destroy, I guess.

Search and replace, not destroy. :-)

>>
>>> 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.

>> 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.

> 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.

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?

--
Ceki