I was surprised to find in the M4 News And Noteworthy list a shortcut to change a concatenated String to StringBuffer.
At first, it looks like a good idea.
String s = "offset " + offset + " is at line " + line;
is changed to:
StringBuffer stringBuffer = new StringBuffer();
stringBuffer.append("offset ");
stringBuffer.append(offset);
stringBuffer.append(" is at line ");
stringBuffer.append(line);
I know using StringBuffers is better for performance UPDATE: I confused StringBuffer with StringBuilder! look at this bug for changing StringBuffer to StringBuilder.
I would have rather been going for this:
NLS.bind("offset {0} is at line {1}", offset, line);
Just because this is so much easier to internationalize.
I have almost finished doing i18n for the BPMN modeler, a component of the STP project, and I really lost time on such cases.
Just my $0.02!
… but not everybody is doing plugin/rcp-development
Actually, using StringBuffer is bad for performance. This old myth is from Java 1.1 days when the compiler did insane things when concatenating strings.
Starting from version 1.2, the compiler generates the code above internally, so you win nothing but loose code readability.
With versions 5, the compiler is using StringBuilder which is much faster than StringBuffer because it’s not synchronized, so this “enhancement” actually harms performance.
Another one chalked up for “futile/harmful optimization attempt”
Agree that your solution looks OK. However, I must express a bit of concern with the quick fix listed in the Eclipse M4 notes. There is something which already does this - it is called a compiler - and it does a much better job. For example if you convert string concatenation to StringBuffer calls on JDK 5+ your code will actually be SLOWER. This is due to the fact that the JDK 5+ code knows about StringBuilder (basically non-synchronized StringBuffer - specifically for these localized examples).
Again, I agree that your solution works well for code that may be internationalized but I just thought I would include a quick comment to make sure no one fell for the old always use StringBuffer myth.
NOTE: there is a case to use StringBuffer when you are streaming - ie, concatenating in a loop.
Furthermore, using StringBuffer makes your code slower than the String concatenation, because StringBuffer is synchronized. And the compiler use StringBuilder for a String concatenation.
Hi,
>I know using StringBuffers is better for performance.
Thats wrong (it was right in Java 1.0)
It is the compiler’s task to make this optimization. And indeed, the Java 1.5 compiler uses StringBuffers.
Since Java 6, the compiler uses StringBuilder if possible, which has an even better performance. This better performance can only be achieved, if there is NO explicit reference to StringBuffer.
So using StringBuffer in this case is a really bad idea that prevents performance optimizations. And you’re right, it makes the code less readable.
Cheers, Gerd
Tom, even if you are not, at some point you’ll need to internationalize your product. In that case, you will need to be able to place the bindings in the string in different places, depending on the language.
Aaron, this is a valid point! I had confused the two. I’ll update the blog post and will open a bug.