Strings

String is immutable in Java. An immutable class is simply a class whose instances cannot be modified. All information in an instance is initialized when the instance is created and the information cannot be modified. There are many advantages of immutable classes. This article summarizes why is String designed to be immutable. This post illustrates the immutability concept from the perspective of memory, synchronization and data structures.

1. The requirement of String Pool

String pool (String intern pool) is a special storage area in the Method Area. When a string is created and if the string already exists in the pool, the reference of the existing string will be returned, instead of creating a new object.

The following code will create only one string object in the heap.

String string1 = "abcd";
String string2 = "abcd";

Here is how it looks:

If a string is mutable, changing the string with one reference will lead to the wrong value for the other references.

2. Caching Hashcode

The hash code of a string is frequently used in Java. For example, in a HashMap or HashSet. Being immutable guarantees that hashcode will always be the same so that it can be cashed without worrying about the changes. That means, there is no need to calculate hashcode every time it is used. This is more efficient.

In String class, it has the following code:

private int hash;//this is used to cache hash code.

3. Facilitating the Use of Other Objects

To make this concrete, consider the following program:

HashSet<String> set = new HashSet<String>();
set.add(new String("a"));
set.add(new String("b"));
set.add(new String("c"));
 
for(String a: set)
  a.value = "a";

In this example, if String is mutable, its value can be changed which would violate the design of set (set contains unduplicated elements). Of curse, the example above is just for demonstration purpose and there is no field value in a real string class.

4. Security

The string is widely used as a parameter for many java classes, e.g. network connection, opening files, etc. Were String not immutable, a connection or file would be changed and this can lead to a serious security threat. The method thought it was connecting to one machine, but was not. Mutable strings could cause a security problem in Reflection too, as the parameters are strings.

Here is a code example:

boolean connect(string s){
    if (!isSecure(s)) { 
throw new SecurityException(); 
}
    //here will cause problem, if s is changed before this by using other references.    
    causeProblem(s);
}

5. Immutable objects are naturally thread-safe

Because immutable objects can not be changed, they can be shared among multiple threads freely. This eliminates the requirements of doing synchronization.

In summary, String is designed to be immutable for efficiency and security reasons. This is also the reason why immutable classes are preferred in many cases in general.

StringBuffer & StringBuilder

Since String is immutable in Java this means once you create a String you cannot change it. But there are always the cases you wanna modify a String, for example, you may use “+” to compact two Strings or you may wanna get the uppercase of the given String etc, these operations generate a new String and discard the older String for garbage collection.

These are heavy operations and generate a lot of garbage in heap. So Java has provided StringBuffer and StringBuilder class that should be used for String manipulation.

StringBuilder and StringBuffer are mutable objects provide some useful methods for manipulating String. The String is not turned into “concrete product” until we call a certain method of StringBuilder & StringBuffer. This brings the flexibility of manipulating the String Object.

StringBuilder vs StringBuffer

StringBuffer was the only choice for String manipulation till Java 1.4 but it has one disadvantage that all of its public methods are synchronized. StringBuffer provides Thread safety but on a performance cost.

In most of the scenarios, we don’t use String in a multithreaded environment, so Java 1.5 introduced a new class StringBuilder that is similar with StringBuffer except thread safety and synchronization.

So if you are in a single threaded environment or don’t care about thread safety, you should use StringBuilder else use StringBuffer.

We will only talk about StringBuilder later since the only difference between StringBuilder & StringBuffer is that StringBuffer is used for multithread environment.

StringBuilder

StringBuilder objects are like String objects, except that they can be modified. Internally, these objects are treated like variable-length arrays that contain a sequence of characters. At any point, the length and content of the sequence can be changed through method invocations.

Strings should always be used unless string builders offer an advantage in terms of simpler code (see the sample program at the end of this section) or better performance. For example, if you need to concatenate a large number of strings, appending to a StringBuilder object is more efficient.

// creates empty builder, capacity 16
StringBuilder sb = new StringBuilder();
// adds 9 character string at beginning
sb.append("Greetings");

package stringdemo;

public class StringBuilderDemo {
    public static void main(String[] args) {
        StringBuilder stringBuilder = new StringBuilder();
        stringBuilder.append("Andrew ");
        stringBuilder.append("Programming");

        String result = stringBuilder.toString();
        System.out.println("Result:" + result);


        String rs = stringBuilder.reverse().toString();
        System.out.println("Reverse Result:" + rs);

        stringBuilder.reverse();
        String insertResult = stringBuilder.insert(stringBuilder.length(), " Is Great!").toString();
        System.out.println("Insert Result:" + insertResult);


    }
}

Result:Andrew Programming
Reverse Result:gnimmargorP werdnA
Insert Result:Andrew Programming Is Great!