This will never change, a lot of code has been done with this premise. It could one day have something additional, in a way it already has that is the StringBuilder
.
In a general way it is not harmful in performance so that it is worth being different. Java, like some other languages, does not aim to have the best possible performance but the most suitable performance for most situations. Surely lose at some things and win at others.
Competition
One reason to be so is the competition. It is very difficult to deal with mutable objects when access can be done on threads different. Today this is very important. Treat access to string Concurrent mode changeable is bad from the performance point of view because it requires locking. That alone already has a cost. And worse, this cost can be paid even if you’re not doing anything concurrent. It’s done "just in case". You can even optimize it, but it’s very complicated.
Protecting
Imagine you are given a file name to open, then the file name is changed by another thread and then the operation that was valid is no longer. What is the solution? You would have to stop the string throughout the operation. Only there may be other parts of the code that need to manipulate this string You can’t do anything anymore, you have to wait. You can release it soon, or take hours, days, it’s not viable. What’s the solution? Copy the content, so you have a new object. But you may have copied something that will not even be changed by another thread. So the copy made was a wastage. In most cases this is what happens.
Strings Mutables play the responsibility of protecting the text for anyone who reads it. Most of the time this protection is not necessary, but you pay the price anyway, because there is no way to know when it will be necessary or not, except in extremely simple code, which is not the case of language libraries. These copies never know if there may be a competition problem or not.
Protection in the right place
Strings immutable put the cost of protecting the text to anyone who changes its value. Writing occurs very little in a code. It is better to pay this price.
If you know you have a case that will make several changes use the StringBuilder
and then convert to String
(related). That’s a string changeable and not made for indiscriminate use, should be used at a specific point and never shared between threads.
Hashing
It hinders or even prevents its use as keys to structures such as HashMap
. If the code hash of string easy mute, need to reorganize the Buckets of the structure at all times.
Other reasons
- Strings are more insecure (improper access)
- Make caching difficult
- And the reuse of (interning for Flyweight)
- In addition to compile-time optimizations
- Reflection gets much more complicated.
There are good answers on the Soen, and a look http://stackoverflow.com/questions/22397861/why-is-string-immutable-in-java
– Giovane
Thanks to String being immutable, JVM can maintain a single instance of a given String and share it with other places that use this same value. This can result in a memory saving.
– Marcos Tanaka