StringBuilder/StringBuffer vs. "+" Operator

Using String concatenation is translated into StringBuilder operations by the compiler.

To see how the compiler is doing I'll take a sample class, compile it and decompile it with jad to see what's the generated bytecode.

Original class:

public void method1() {
    System.out.println("The answer is: " + 42);
}

public void method2(int value) {
    System.out.println("The answer is: " + value);
}

public void method3(int value) {
    String a = "The answer is: " + value;
    System.out.println(a + " what is the question ?");
}

The decompiled class:

public void method1()
{
    System.out.println("The answer is: 42");
}

public void method2(int value)
{
    System.out.println((new StringBuilder("The answer is: ")).append(value).toString());
}

public void method3(int value)
{
    String a = (new StringBuilder("The answer is: ")).append(value).toString();
    System.out.println((new StringBuilder(String.valueOf(a))).append(" what is the question ?").toString());
}

• On method1 the compiler performed the operation at compile time.
• On method2 the String concatenation is equivalent to manually use StringBuilder.
• On method3 the String concatenation is definitely bad as the compiler is creating a second StringBuilder rather than reusing the previous one.

So my simple rule is that concatenations are good unless you need to concatenate the result again: for instance in loops or when you need to store an intermediate result.

Your team needs to learn about the reasons for avoiding repeated string concatenation.

There certainly are times when it makes sense to use StringBuffer - in particular when you're creating a string in a loop, especially if you aren't sure that there will be few iterations in the loop. Note that it's not just a matter of creating new objects - it's a matter of copying all the text data you've appended already. Also bear in mind that object allocation is only "essentially free" if you don't consider garbage collection. Yes, if there's enough room in the current generation, it's basically a matter of incrementing a pointer... but:

• That memory must have been cleared at some point. That's not free.
• You're shortening the time until the next GC is required. GC isn't free.
• If your object lives into the next generation, it may take longer to be cleaned up - again, not free.

All of these things are reasonably cheap in that it's "usually" not worth bending a design away from elegance to avoid creating objects... but you shouldn't regard them as free.

On the other hand, there is no point in using StringBuffer in cases where you won't need the intermediate strings. For example:

String x = a + b + c + d;

is at least as efficient as:

StringBuffer buffer = new StringBuffer();
buffer.append(a);
buffer.append(b);
buffer.append(c);
buffer.append(d);
String x = buffer.toString();

For small concatenations you can simply use String and + for the sake of readability. Performance is not going to suffer. But if you are doing lots of concatenation operations go for StringBuffer.