Let's have a look round in the world of logging.
There is a glorious article in the Wikipedia about fundamental concepts of logging.
Two (or rather three) competitors are log4j, java logging API == java.util.logging == JUL == JSR47 and Java Commons Logging == JCL. The latter is not a real logging framework, just an adapter which quests for the available framework in runtime and uses it. It can be helpful when we don't want to wrap some modul to log4j, JUL or anything, however, it has disadvantages regarding efficiency and functionality. See this article about it: Think again before adopting the commons-logging API
Here is an opinion about differences between log4j and JUL. I've read it a long time ago and deeply agree with it with the supplement, that because of the continuous inconveniences I hate Java Logging API.
(The author of the former article, Ceki Gülcü is the founder of log4j. He has a blog where he writes engaging things. For an example, mentions presentation of Linus Torvalds about GIT vs SVN. Well, I also didn't like that style not to say about this.)
Nowadays it seems that he (Ceki Gülcü) walks differents ways from Apache group, because he is working on the possible posteriors of log4j and JCL, namely LogBack and SLF4J. (Wikipedia article doesn't mentions these.) Theoretically, SLF4J will have log4j support. I don't know how much will be SLF4J efficient but I guess they started to implement a new framework because they wanted to make something better.
log4j exists since Java 1.1, JUL was invented in 1.4. By exploring homepage of log4j it turns out soon that there's no version which exploits advantages of Java 5.0. Log4j 2.0 would have been the one which fulfils this task, but there are not too much (any) visible activity in this subject.
However, LogBack and SLF4J are going to be in a useable shape soon. LogBack has version 0.9.X nowadays. On our Hungarian forum there was a flame about logBack and using isDebugEnabled. First important consequence was for me, that people do log in many different styles and it depends on the developed application. Somebody can use toString often, somebody doesn't have this possibility. Secondly, isDebugEnabled condition can't be dropped out in every cases, just when there are no expressions in the parameter list. (For sample, explicit high-cost function calls.) By the way, using varargs instead of String evaluation can be rather beneficial during logging.
Which one would I choose? In conservative software modules, when embedding environment may not be log4j-based I would choose JCL. Otherwise I would use log4j. At newly started projects I would use LogBack or SLF4J, although I would get a line if there are existing appenders which I should use. Regarding log4j, (as it is an old professional in the scene) there are a lot of appenders.
(This was a translation again. See original here in Hungarian.)
There is a glorious article in the Wikipedia about fundamental concepts of logging.
Two (or rather three) competitors are log4j, java logging API == java.util.logging == JUL == JSR47 and Java Commons Logging == JCL. The latter is not a real logging framework, just an adapter which quests for the available framework in runtime and uses it. It can be helpful when we don't want to wrap some modul to log4j, JUL or anything, however, it has disadvantages regarding efficiency and functionality. See this article about it: Think again before adopting the commons-logging API
Here is an opinion about differences between log4j and JUL. I've read it a long time ago and deeply agree with it with the supplement, that because of the continuous inconveniences I hate Java Logging API.
(The author of the former article, Ceki Gülcü is the founder of log4j. He has a blog where he writes engaging things. For an example, mentions presentation of Linus Torvalds about GIT vs SVN. Well, I also didn't like that style not to say about this.)
Nowadays it seems that he (Ceki Gülcü) walks differents ways from Apache group, because he is working on the possible posteriors of log4j and JCL, namely LogBack and SLF4J. (Wikipedia article doesn't mentions these.) Theoretically, SLF4J will have log4j support. I don't know how much will be SLF4J efficient but I guess they started to implement a new framework because they wanted to make something better.
log4j exists since Java 1.1, JUL was invented in 1.4. By exploring homepage of log4j it turns out soon that there's no version which exploits advantages of Java 5.0. Log4j 2.0 would have been the one which fulfils this task, but there are not too much (any) visible activity in this subject.
However, LogBack and SLF4J are going to be in a useable shape soon. LogBack has version 0.9.X nowadays. On our Hungarian forum there was a flame about logBack and using isDebugEnabled. First important consequence was for me, that people do log in many different styles and it depends on the developed application. Somebody can use toString often, somebody doesn't have this possibility. Secondly, isDebugEnabled condition can't be dropped out in every cases, just when there are no expressions in the parameter list. (For sample, explicit high-cost function calls.) By the way, using varargs instead of String evaluation can be rather beneficial during logging.
Which one would I choose? In conservative software modules, when embedding environment may not be log4j-based I would choose JCL. Otherwise I would use log4j. At newly started projects I would use LogBack or SLF4J, although I would get a line if there are existing appenders which I should use. Regarding log4j, (as it is an old professional in the scene) there are a lot of appenders.
(This was a translation again. See original here in Hungarian.)
Comments