Thanks for the tip. I suppose it still makes a method call and few references pushed onto the stack, yes? A major saving over the alternative I suppose...
(And regards history) - Now we are going back to printf() style conventions. How amusing. -----Original Message----- From: Curt Arnold [mailto:[EMAIL PROTECTED] Sent: Wednesday, 11 June 2008 3:16 PM To: Log4J Users List Subject: Re: log4j best practises - logger.isDebugEnabled() On Jun 10, 2008, at 11:42 PM, Peter Nann wrote: > > I am only a peripheral Log4J User, however my peers recently advised > that all our logging should be written like: > > if(logger.isDebugEnabled()) { > logger.debug("Entry number: " + i + " is " + > String.valueOf(entry[i])); } > > Personally, I think that is an absolute abomination, and a major > failure of the logging framework / Java combination. > > That amount of extraneous 'noise', required typing (probably), and > usage of screen real-estate in the source code will clearly discourage > regular usage of detailed logging output. > > When most methods should be a handful of lines, and most methods > should be able to log at the most detailed log level, that amount of > overhead is really annoying. > > Completely unacceptable in my books. > > It should be simple, succent and efficient. > > For gods sake, this was all figured out in the 70's with the C > pre-processor. > OK, not really Log4J's problem - More a Java limitation... > And yes, I have been pointed to Aspect compiler solutions (Almost > passable). > > > I'm just dissappointed that the solution here is not very elegant, > given the maturity of Java. > > > Sigh, history so often repeats itself... > > I would recommend using LogMF in the extras companion (or use LogSF if you have to maintain code that uses log4j 1.3/SLF4J format strings instead of java.text.MessageFormat message strings). LogMF.debug(logger, "Entry number: {0} is {1}", i, entry[i]); LogMF goes to a lot of effort to make that efficient and the you'd be hard pressed to beat it with custom code. It shortcircuits if the threshold is not met and avoids the unconditional array creation that a varargs approach would entail. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
