Unfortunately, this is not quite how it works.

To the best of my understanding there are two components to the optimization of String concatenations. The first one happens at compile time replacing those String concatenations with either StringBuilder calls (Java 8) or StringConcatFactory calls (Java >8). The second component is only implemented for Java >8 and takes place in the JVM translating those StringConcatFactory calls to a concrete String concatenation implementation of the JVM's choosing.

A prerequisite for this to work is that the compiler is able to optimize this at compile time. This is why concatenations carried out in loops cannot be optimized. More precisely,

String result = "";
for (int i = 0; i < 25; i++) {
  result = result + "counter=" + i;
}

This would result in one StringBuilder being instantiated for each concatenation in the loop. That's an improvement, but not the comprehensive optimization of only having a single StringBuilder for all concatenations.

When it comes to the use of other flow controls (conditional blocks, methods) I would assume that this cannot be determined at compile time either.

So in my understanding I would only use this in simple scenarios such as a locally confined concatenation:

public String toString() {
  return this.fieldA + this.fieldB + this.fieldC;
}

I apologize if my previous explanation was cut too short and thus misleading.

refs

• https://howtodoinjava.com/java/string/string-concatenation-performance/
• https://marxsoftware.blogspot.com/2019/01/jep-280-indify-string-concatenations.html
• https://cl4es.github.io/2019/05/14/String-Concat-Redux.html

This patch probably should just be StringBuffer (synchronized) => StringBuilder

This patch probably should just be StringBuffer (synchronized) => StringBuilder

I agree. Provided that thread-safety is not required for these classes

@egonw Do you want me to migrate that over to StringBuilder so that it can then be closed?

Do you want me to migrate that over to StringBuilder so that it can then be closed?

@uli-f, actually not sure. Since some sources suggest that in modern JVMs just using "foo" + "bar" can be optimized JIT pretty well, I was not entirely sure what the best approach is. Thanks for the ping!

https://howtodoinjava.com/java/string/string-concatenation-performance/ writes:

Since Java 9, String concatenation is a runtime decision, not a compile time one anymore. It means that after you the code Java 9 (or later) and it can change the underlying implementation however it pleases, without the need to re-compile.

@johnmay, what do you think?

Well the StringBuffer should go for sure, but I have no strong feeling on just using + vs a StringBuilder. Personally here I would probably use StringBuilder here but this isn't going to be a performance critical so doesn't matter what is done.

My reading of that article is mainly on a simple cases bases.

The invokedynamic call to java.lang.invoke.StringConcatFactory offers the facilities for a lazy linkage

In this case the files has multiple concats at different parts I so I think it's unlikely to be able to optimise across those and a StringBuilder is likely better.

@uli-f, conclusion: yes, please update to use the StringBuilder.

@uli-f, conclusion: yes, please update to use the StringBuilder.

Okay, will migrate to StringBuilder then.

Super seeded by #1150