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.

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.