That's actually what the compiler will generate from your previous statement. It uses StringBuffer to implement concatenation. As long as you have the concatenation in the same statement, you would not gain anything by creating your own StringBuffer. Now if you had the concatenation spanning several statements:
it would create a number of StringBuffers, one for each concatenation. This may or may not be a big deal depending on your situation. Now, why build that String in the first place if you are never going to use it, like if the debug level is above INFO? The Log4J manual recommends checking if the String is needed before constructing it:
Log4J also has methods which let you use message parameters, so the string doesn't get created unless it is used:
That's more useful for internationalization, though - simple string concatenation will likely be faster, anyway.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Um, java.util.logging does have equivalent methods. The java.util.logging version is:
They haven't provided corresponding overloads for info() etc, so you have to specify Level directly with the first parameter. And now that JDK 5 is out, you'd think they would have replaced that final array with a vararg so we don't have to say "new Object" - but they haven't, yet. Feel free to vote for this bug if you'd like to see this trivial change made to enhance usability of java.util.logging. Actually as I think about it, it would be even better if Logger had methods which use the new Formatter functionality, as that's much more powerful and already integrated into widely-used classes like String and PrintStream (with methods like printf()).