Concatenating Strings in Java 9
Concatenating Strings in Java 9
In this article, we discuss the change on how String concatenation works in Java 8 when compared to Java 9.
Join the DZone community and get the full member experience.Join For Free
Have you ever had the need to build a comma-separated list of values from a list or an array in Java or wanted to create a file path using concatenated folder names and a file path delimiter? Well, in the article Cocatenating Strings in Java 8, I have described a convinient way to use Java 8 APIs to do the job.
This not only reduces your development time and prevents additional errors, but it also let's you write more readable and understandable code. But what exactly happened since Java 9 was released, and does it apply to the code presented in the cases described in the aforementioned article.
When you implemented your first application in Java or read some Java books and articles, you probably noticed that you shouldn’t concatenate Strings with + operator. And that’s correct if you’re concatenating Strings in your application logic.
Strings are immutable, and the result of each String concatenation is stored in a new String object. That requires additional memory and slows down your application, especially if you’re concatenating multiple Strings within a loop. Experienced Java programmers know that using a class StringBuffer to append String values was the preferred approach, and as of release JDK 5, this class has been supplemented with an equivalent class designed for use by a single thread, called StringBuilder. StringBuilder should generally be used in preference to StringBuffer, as it supports all of the same operations, but it is faster, as it performs no synchronization.
Now, let us revisit an example from my previous article:
When the String's join method is called, it delegates the calls to a slightly more sophisticated class, called StringJoiner, which in fact offers more than just concatenating strings with a parametrized delimiter. As the Javadoc states:
StringJoiner is used to construct a sequence of characters separated
by a delimiter and optionally starting with a supplied prefix and ending with a supplied suffix.
In Java 8, the StringJoiner implementation is optimized for Strings concatenation and is based on the usage of StringBuilder. By using the Java API for building comma-separated values, we were sure that our code was optimized for the use case of having a lot of values that have to be concatenated in on String value. The integration of the StringJoiner in Java Collectors API for Streams was a huge benefit for us as well. But since then, Java 9 changed the game.
In Java 9, each String concatenation is translated into a call to invokedynamic, as described in JDK Enhancement Proposal 280. JEP 280 changed the static String-concatenation bytecode sequence generated by javac to use invokedynamic calls to JDK library functions. This enables future optimizations of String concatenation without requiring further changes to the bytecode emitted by Java.
What this generally means is that concatenating String values with the + operator turns out to be faster when compared to using StringBuilder, which was earlier used in the Java 8 bytecode when simple + concatenation optimizations were applied.
But what happens to the legacy code we have already written like the one below, based on StringJoiner and Collectors for String concatenation:
Well, the StringJoiner class was also changed since Java 9 and does not use the StringBuilder any more. Instead of storing the values in a StringBuilder, an array of String values is used, and the concatenation is based on the method, getChars, provided by String:
This change is just an implementation detail that does not directly relate to the Java 9 String concatenation changes. As a matter of fact, for huge lists with millions of elements, the new version performs better, as it does not depend on a Java class (StringBuilder) but on native methods invoked in the String class implementation.
The good news is the Java API for building comma-separated values is still valid and has been improved since Java 9. More importantly, it makes sense to rely on the Java APIs instead of using custom implementations or external libraries because moving to newer Java versions might optimize your legacy code without the need to rewrite, deploy, and publish any new releases of your old code.
Opinions expressed by DZone contributors are their own.