I would leave out the StringBuilder change. That was put in for performance, and indeed may well be outdated, with so much compiler work since. But before doing this, let's see if it doesn't make things slower, to be sure. If not, we can apply this at a lot more places in the core classes. So, imo, better as a separate patch/PR.

But happy with the API extension. We do need tests for the new functionality.

Thanks Egon for your feedback.

I was big on putting StringBuilder everywhere, until I read this recently. In summary: with Java 8 the compiler transforms the concatenation into StringBuilder calls, so nothing gained, nothing lost. With Java >8, StringBuilder is actually not even recommended as the string concatenation allows the JVM to choose the best implementation at runtime (JEP 280).

Basically, less typing, less convoluted code, better result 😃

Have a look and let me know what you think.

I'll put in the tests you asked for.

I was big on putting StringBuilder everywhere, until I read this recently. In summary: with Java 8 the compiler transforms the concatenation into StringBuilder calls, so nothing gained, nothing lost. With Java >8, StringBuilder is actually not even recommended as the string concatenation allows the JVM to choose the best implementation at runtime (JEP 280).

Great! Let's make this a todo.

Great! Let's make this a todo.

And just to clarify: This compiler / jvm optimization obviously only works if it can be inferred at compile time. For example, if a string concatenation happens in any loop, StringBuilder must still be used to not loose any performance.

Added tests.

@egonw I haven't removed the StringBuilder replacement, but I am happy to if you still prefer it to be removed. Just let me know.

but I am happy to if you still prefer it to be removed. Just let me know.

Nah, that can stay in.

All looks good to me, not a breaking change since it is adding and not changing the API.