why strings are immutable???

Can some one tell me why string are immutable?
There is link http://www.acooke.org/andrew/immutable.html explaining it but i want to know answer from multithreading perspective.
Can some one explain this comparing it with StringBuffer.
Thanks

Well, the quoted article is pretty good, but...

An immutable object is convenient in some multi-threaded applications. If given a reference to an immutable object, there is no need to consider whether synchronisation is necessary (*), to prevent a thread seeing unexpected, or even part-complete, modifications to that object. So, if a thread in a multi-threaded application has been given a reference to a String by another thread, it does not have to worry that the other thread might unexpectedly change the String.

In contrast, if given a reference to a mutable object, like a StringBuffer, one thread does have to consider whether another thread might be modifying it at the same time. Some sort of synchronisation policy has to be devised and adhered-to, or Bad Things (tm) will happen.

(*) When I say that there is no need to consider synchronisation, I mean purely in the narrow context of the immutable object itself. If the immutable object is part of some larger data structure, then synchronisation will be necessary, to maintain integrity of the overall data structure.

Thanks for your reply.... but A quick follow up....
I think reason that you have given is TRUE FOR ANY IMMUTABLE OBJECT... I was just wondering why java have not provided String implementation one like that of say ArrayList ( or any other collection class as matter of fact )... where it is mutable by deafult... but utiltiy methods ( in Collections class ) provide me thread safe and immutable implementation of that object.

Pardon me for my wiered analogy... but i realy want to get into the fact....

[ August 05, 2004: Message edited by: Rajan Punchouty ]
[ August 05, 2004: Message edited by: Rajan Punchouty ]

Rajan,

You're exactly right, and this reason is true for any immutable object.

We might have found it convenient if String and StringBuffer had shared a common interface (IString perhaps?) and StringBuffer had a more 'complete' set of methods.

Then StringBuffer would be a fully-functional 'mutable string' and the interface could be used to abstract the difference.

The 'immutable wrapper' design found in the Collections class is a good approach since collections may be large or complex data structures and have many differing types.

This design is not used for Strings since there is only a type of string data (an underlying char[] buffer) and immutable Strings have delegation/ buffer sharing functionality built into the String class itself rather than needing a separate 'immutable delegation' wrapper decoupled from the inheritance heirarchy.

Cheers,
Thomas
www.powermapjdo.com

String and StringBuffer DO share an Interface. Check out java.lang.CharSequence in your API docs.

I must admit the utility of CharSequence is a bit limited but it does exist

One of the main reasons for String immutability is security - just think of the problems you could have if a String could change during an authentication process.

Other advantges of immutability include:
use for caching
thread safety
efficiency, eg substring can be very efficient as a new object does not have to be createdI think it's a good idea to make all objects immutable unless their state has to change or you need to allow for something like subclassing. Developers can be on the lookout for appropriate situations. For instance, if your DTO will never change after its values have been set, then why not make it immutable? You'd need to pass the values into the constructor so that the object can be initialized, but you won't have any setters, just getters.