Strings are immutable by design. Because of this, they make good Map keys, are inherently thread-safe, and you don't have to worry about them being modified as a potential side effect when passing them to other methods.
If you need a mutable string, use StringBuffer/StringBuilder.
Originally posted by Mishra Anshu: In fact read this article
It is good !
Actually, I would say it's pretty bloody awful. The example seems hinges on whether assignment to an object reference changes the object or not -- but of course it doesn't, it never does, whether a class is immutable or not.
Most of the rest of the explanation is decent, although it leaves out the most important reason, which is also absent from the rest of this thread: security.Java is designed to be secure(able). If you could not depend on a String's value staying constant, then it would be extremely hard to write secure network code, for example; you'd have to remember to copy every String that came in as an argument or went out as a return value. Otherwise, Strings like hostnames or usernames could be changed after a security check was done but before they were used.
I recall that Java 1.0 had a security issue because the java.net.URL class wasn't final at that time, and therefore was effectively publically mutable. It made it possible to do an end run around the security sandbox for applets at the time. It was possible to create a URL, ask Java to connect to it, have the URL checked by the SecurityManager, then change the host the URL object referred to, and trick Java into connecting to an unapproved host, all because URL wasn't immutable.
Why is any type immutable? First, one must define immutable. Here's one definition: Where all contract operations are 'pure'. What is 'pure'? One could look at a pure functional programming language like Haskell to answer that in detail, but a quick paraphrase might be something like: When any and all invocations between now and infinity along our given arrow of time will return the 'same value'. One can define 'same value' as being 'some contract that is itself pure (all operations pure)'.
So now why immutable? Pure functional programming has many advantages - for example, the ability to provide a proof of the outcome. In contrast, OO is the opposite of 'pure' by definition - for example, you can invoke a 'set' operation (impure) and observe an effect on a 'get' operation (also impure). This consequence has seen an abundance of publications by people trying to come up with the 'correct' way of using OO - all failing (that I have seen anyway) to notice that their arguments lies on a flawed premise - the legitimacy of OO. Of course, one may redefine OO to make it legitimate, but such a definition is incredibly unorthodox and doesn't go down well with the establishment. This leads to rifts in communication - trust me, I have tried it - and I have since conceded.
In your case, and since IBM are entirely "how things appear" driven, I expect that the answer would be some reiteration of marketing material that is published by either Sun or IBM. For example, I can imagine answers like 'because it is easier to manage' or 'you can share copies and gain performance benefits' and I'll also expect some other more formal answers to be stipulated in the articles that are provided by others.
So to rephrase your question - it is not "why are Strings immutable?" - it is "what does IBM want me to think in terms of Strings being immutable?". I expect it is the latter case that you after. Don't be fooled into thinking that these two questions are in any way equivalent. I have worked on IBM software that clearly indicates incompetence on behalf of the developers and subsequent management to such an extreme that I'd consider failing my first year university assignments should they submit such a 'thing'. Nobody in IBM truly understands why String is immutable - not even him (I'm assuming what you're thinking - since I just insulted one of the dieties).
The marketers do the clever stuff, but be aware of the intentional blur that they portray. Having understood this, it is important to also understand the context in which you are answering the question by the interviewer. As I have attempted to point out, it is not entirely a technical question - in fact, it is quite the opposite. You have submitted the question on a forum of people who attempt to answer the question in a technical context. While this is advantageous, it is important to know how to apply any of the information that you have gleaned, in your given non-techical ("how this appear" not "how things are") context.