This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hm, I agree for most situations, but if the expression in the parameter of the log statement is something "expensive" like retrieving an attribute from an entity bean or maybe a larger calculation I think it may make sense to add an if statement, because without it the parameter will be evaluated before the method debug() is called.
But you don't have to declare a constant, because you can use the method isDebugEnabled() from log4j.
for example (I have to admit this is a little theoretical):
Correct me if I am wrong here. In order for the compiler to throw away code, shouldn't the if statement refer to a compile time constant?
Method call is not compile time constant right?
My goal is to let compiler throw away all the debug method call to save space. Considering this, above code kind of defeat the purpose right?
Joined: Aug 25, 2006
Jeanne Boyarsky wrote:Peter,
In theory. The thing is the amount of time to call a method is trivial. Creating extra code all over to deal with it isn't worth the maintenance complexity.
Log4j does shield you from the actual logging and processing if the level does not match though.
I agree. Java programmers care more about robustness and readability than efficiency. However, in the extreme example when I have debug code everywhere and my program need to run on a mobile device on release, would this be a concern?
One other thing: if you find using logger.isDebugEnabled() tedious, there is some functionality available that were developed for the abandoned log4j 1.3 version that makes building strings on-the-fly efficiently less tedious by using MessageFormat. Rather than this:
one would write:
In my opinion it is easier to read than the isDebugEnabled() alternative.
See LogMF for more on that class and see Apache Extras Companion for more on the package.