Log5j and The State of Log4j Version 2
I just took log5j for a spin. For those who does not know, log5j is a Java5 enhancement of the log4j api. It provides two new features on top of log4j, where one is made possible by Java5:
- Feature 1: Obtain a logger without giving the logger name (which is bad, I think)
- Feature 2: Using printf-style formatting in the log statements (good thing, I think)
Printf Style Formatting
Let us take the good stuff first. Using log5j, it is now possible to log like this:
LOG.debug("%s called me with %d", "foo", 5);
using the new Java5 printf style formatting. Nice.
That is about it.
No Logger Name in Logger Construction
Now, to what I find a bit more troublesome. In log5j, it is now possible to construct a Logger instance like this:
private static final Logger LOG = Logger.getLogger();
this is different from log4j, in that you do not give a logger name to the getLogger() method call. It obtains this itself, from the stacktrace. Here is the code from within log5j, which does it:
String name = new Exception().getStackTrace()[1].getClassName();
The implementation simply assumes, that the logger name should be the one-up in the call-stack. Does this always hold? What about dynamic proxies and stuff like that? Okay, granted, we might not be proxying Logger that often, but log5j cannot be sure, that one-up in the call-stack is a safe bet, can it.
Another thing is, being based on Java5, it should be using Thread.currentThread.getStackTrace(), but I guess that can be easily fixed 
The Package Name
One extra thing. The code in log5j is packaged in a com.spinn3r.log5j package. I know it is no practical problem, but I would hate having such a package name strewn all over my source code. And it sure will be strewn all over, being the main api to the logging system. But maybe that is just me.
Log4j Version 2
So, should we start using log5j?
Log4j is an old api, but it works. For Java5 printf style, we could just use this style:
LOG.debug(format("%s called me with %d", "foo", 5));
and then add a static import for String.format, even though it is a bit more work and typing.
But what about log4j version 2? Well, there once was a log4j version 1.3.x development branch, but it has been discontinued, due to severe problems keeping compatible with log4j v1.2.x. And I guess backward compatibility is of extreme importance, with something like a logging api. There is a log4j version 2.x development branch though. And what will that bring us? It says, that log4j version 2 is “designed for JDK 1.5 and higher”, but it also says that “…Some early experiments for log4j 2.0 are in the sandbox, but it hasn’t been built out to a functioning framework yet”. Hmmm.
What it seems like, is that development is going on in the new logback project, instead.
March 9, 2008
Tags: Java, log4j, log5j Posted in: Programming
2 Responses
Actually, log5j follows a recommendation of Heinz Kabutz:
http://www.javaspecialists.co.za/archive/newsletter.do?issue=137
Which is reasonable. The point is that there is no “class.this” reference to the enclosing class in java, and copy-paste problems could occur, apart from the typing of redundant information.
As for the printf, I don’t know who would want to use something as slow in a logging statement. Is this a feature to have nicer printing lines or to remove the need to do this?
if (log.isInfoEnabled(…)) {
…
}
Hi Dimitris,
Yeah, I know, there is no class.this in the static context. And I also duplicate the classname. I have not found it a problem though, in the sense of copy-paste bugs. But it can happen, I agree. I *would* like the simple non-parameter, getLogger()-call, if I can be sure, the “one-up in the call stack” implementation always hold. That was a question!?
For printf: For me, I don’t care much for “log.isDebugEnabled” anymore. I used to, though. For me, printf over string concat is all about better readability of the code, now. Sure, there can be specific places where isDebugEnabled() makes sense (like an expensive loop, debugging something out), but they are rare. In my opinion. I really like having readable code, an area where printf shines more than string concat, I think.
Leave a Reply