Showing posts with label Immutable. Show all posts
Showing posts with label Immutable. Show all posts

Thursday, 19 June 2014

Why String is immutable in Java ?

This is an old yet still popular question. There are multiple reasons that String is designed to be immutable in Java. A good answer depends on good understanding of memory, synchronization, data structures, etc. In the following, I will summarize some answers.


1. Requirement of String Pool
String pool (String intern pool) is a special storage area in Java heap. 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 and returning its reference.

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

The following code will create only one string object in the heap.
1.String string1 = "abcd";
2.String string2 = "abcd";
Here is how it looks:

2. Allow String to Cache its Hashcode
The hashcode of string is frequently used in Java. For example, in a HashMap. Being immutable guarantees that hashcode will always the same, so that it can be cashed without worrying the changes.That means, there is no need to calculate hashcode every time it is used. This is more efficient.

3. Security & Thread Safety.
String is widely used as parameter for many java classes, e.g. network connection, opening files, etc. Were String not immutable, a connection or file would be changed and lead to serious security threat. The method thought it was connecting to one machine, but was not. Mutable strings could cause security problem in Reflection too, as the parameters are strings.
Consider a scenario, in a banking application for money transfer - the beneficiary account number is defined in a string as "0123456789". If by mistake/intentionally this acc. number is changed, money will go to a wrong account.
Here is a code example:
1.boolean connect(string s){
2.if (!isSecure(s)) {
3.throw new SecurityException();
4.}
5.//here will cause problem, if s is changed before this by using other references.   
6.causeProblem(s);
7.}