Why is String immutable in Java?

Reasons I can recall :

1. String Pool facility without making string immutable is not possible at all because in case of string pool one string object/literal e.g. "XYZ" will be referenced by many reference variables , so if any one of them changes the value others will be automatically gets affected .

2. String has been widely used as parameter for many java classes e.g. for opening network connection , for opening database connection, opening files . If String is not immutable, this would lead to serious security threat .

3. Immutability allows String to cache its hashcode.

4. Makes it thread-safe .

The Java Virtual Machine performs several optimizations regarding string operations which couldn't be performed otherwise. For example, if you had a string with value "Mississippi" and you assigned "Mississippi".substring(0, 4) to another string, as far as you know, a copy was made of the first four characters to make "Miss". What you don't know is that both share the same original string "Mississippi" with one being the owner and the other being a reference of that string from position 0 to 4. (The reference to the owner prevents the owner from being collected by the garbage collector when the owner goes out of scope)

This is trivial for a string as small as "Mississippi", but with larger strings and multiple operations, not having to copy the string is a big time saver! If strings were mutable, then you could not do this, because modifying the original would affect the substring "copies" as well.

Also, as Donal mentions, the advantage would be greatly weighed down by its disadvantage. Imagine that you write a program which depends on a library and you use a function which returns a string. How could you be sure that that value will remain constant? To ensure no such thing happens, you'd always have to produce a copy.

What if you have two threads sharing the same string? You wouldn't want to be reading a string that is currently being rewritten by another thread, would you? String would then therefore have to be thread safe, which being the common class that it is, would make virtually every Java program that much slower. Otherwise, you'd have to make a copy for every thread which requires that string or you would have to put the code using that string in a synchronize block, both of which only slow down your program.

For all these reasons, that was one of the early decisions made for Java in order to differentiate itself from C++.

Immutability means that constants held by classes that you don't own can't be modified. Classes that you don't own include those that are in the core of the implementation of Java, and strings that shouldn't be modified include things like security tokens, service addresses, etc. You really shouldn't be able to modify those sorts of things (and this applies doubly when operating in sandboxed mode).

If String wasn't immutable, every time you retrieved it from some context which didn't want the string's contents changed under its feet, you'd have to take a copy “just in case”. That gets very expensive.

The reason for string's immutability comes from consistency with other primitive types in the language. If you have an int containing the value 42, and you add the value 1 to it, you don't change the 42. You get a new value, 43, which is completely unrelated to the starting values. Mutating primitives other than string makes no conceptual sense; and as such programs that treat strings as immutable are often easier to reason about and understand.

Moreover, Java really provides both mutable and immutable strings, as you see with StringBuilder; really, only the default is the immutable string. If you want to pass references to StringBuilder around everywhere you are perfectly welcome to do so. Java uses separate types (String and StringBuilder) for these concepts because it doesn't have support for expressing mutability or lack thereof in its type system. In languages which have support for immutability in their type systems (e.g. C++'s const), there is often a single string type which serves both purposes.

Yes, having string be immutable allows one to implement some optimizations specific to immutable strings, such as interning, and allows passing string references around without synchronization across threads. However, this confuses the mechanism with the intended goal of a language with a simple and consistent type system. I liken this to how everyone thinks of garbage collection the wrong way; garbage collection is not "reclamation of unused memory"; it is "simulating a computer with unlimited memory". The discussed performance optimizations are things that are done to make the goal of immutable strings perform well on real machines; not the reason for such strings to be immutable in the first place.

Imagine a system where you accept some data, verify its correctness and then pass it on (to be stored in a DB, for example).

Assuming that data is a String and it has to be at least 5 characters long. Your method looks something like this:

public void handle(String input) {
  if (input.length() < 5) {
    throw new IllegalArgumentException();
  }
  storeInDatabase(input);
}

Now we can agree, that when storeInDatabase is called here, the input will fit the requirement. But if String were mutable, then the caller could alter the input object (from another thread) right after it has been verified and before it's been stored in the database. This would require good timing and would probably not go well every time, but occasionally, he'd be able to get you to store invalid values in the database.

Immutable data types are a very simply solution to this (and a lot of related) problems: whenever you check some value, you can depend on the fact that the checked condition is still true later on.

1. they are expensive and keeping them immutable allows for such things as sub strings sharing the byte array of the main string. (speed boost also as do not need to make a new byte array and copy over)

2. security - would not want your package or class code to be re named

   [removed old 3 looked at StringBuilder src - it does not share memory with string (until modified) I think that was in 1.3 or 1.4]

3. cache hashmap

4. for mutalble strings use SB (builder or buffer as needed)