Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Why is the String Class Immutable?

 
nitin pai
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why is String implemented as a immutable class. If you however want an object in which the text can be manipulated you use the StringBuilder class. Then what was the exact purpose to make String class immutable. We could have used it directly in place of StringBuilder. Isnt it?
 
Stevi Deter
Ranch Hand
Posts: 265
Hibernate Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are dozens if not hundreds of discussions on the web about why Java Strings are immutable. It is actually interesting to read the many threads, and I would highly encourage everybody to do so as a way to learn more about the language.

One interesting topic to pursue is that javac itself is written in java, and why that may have impacted the decision to make Strings immutable in Java.

The point is that we're not limited in Java by the immutable nature of Strings; we have StringBuilder and StringBuffer to give us better performance for cases where we need to manipulate Strings.
 
Nicholas Jordan
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, it is like Steve says. Originally there was an issue several languages back, that is followed by preventing the un-intended changing of variables. That would happen because there are so many variables. Then, when the String class was final - I did not fall for it. Sorta conceptually weak but you can change a String to point to a new String. We get into a convoluted reverbaration discussing the matter. I now just read whatever some class is stated to do and take it at that. If worst comes to too bad, I just write a utility class at the end of the file that does what I want and skipp all the skippy peanuts.
 
nitin pai
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok I can understand that this issue has been prevailing from ages. But when a new API is released cant it be changed to become mutable. My question was why it is still the same way even when Java has upgraded its collections framework with Generics.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nitin --

One important reason was that the JVM is designed to enable secure "sandbox" operation, meaning that unknown Java code -- like an applet downloaded from the Internet -- can be run safely. Immutable Strings help ensure that safety.

Here's a concrete example: part of that safety is ensuring that an Applet can contact the server it was downloaded from (to download images, data files, etc) and not other machines (so that once you've downloaded it to your browser behind a firewall, it can't connect to your company's internal database server and suck out all your financial records.) Imagine that Strings are mutable. A rogue applet might ask for a connection to "evilserver.com", passing that server name in a String object. The JVM could check that this server name was OK, and get ready to connect to it. The applet, in another thread, could now change the contents of that String object to "databaseserver.yourcompany.com" at just the right moment; the JVM would then return a connection to the database!

You can think of hundreds of scenarios just like that if Strings are mutable; if they're immutable, all the problems go away. Immutable Strings also result in a substantial performance improvement (no copying Strings, ever!) and memory savings (can reuse them whenever you want.)

So immutable Strings are a good thing.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[NP]: But when a new API is released cant it be changed to become mutable. My question was why it is still the same way even when Java has upgraded its collections framework with Generics.

I suppose in theory Sun could always come out a different API that changes previous behavior. This might well break some existing code however - for example if the code relies on the assumption that a String is immutable (as much code does). But in general, Sun is very, very reluctant to make changes like this that will break exiting code. There are many classes and methods that could be designed better than they were originally, but Sun will not change these because it's very important to keep existing code functioning correctly. Sun will often add new classes and methods, but they are very very reluctant to make other changes to behavior. This is true for many potential issues, not just immutability. The changes to Collections, and generics in general, were the biggest ever made to the language since it came out, and Sun limited these changes (perhaps unfortunately) to be sure that existing code would still function as before. So what I'm saying is, while it's always possible that Sun may change things drastically in the future, it's not generally something worth worrying about, I think. They are fairly conservative about changes.
 
Stevi Deter
Ranch Hand
Posts: 265
Hibernate Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The decision to make String immutable goes beyond just historial compiler issues, and the other contributors to this discussion have given great evidence as to why it's a good decision.

It's fairly standard in advanced programming languages to have immutable strings. For example, C# chose to use immutable strings and provide a StringBuilder class for cases where this behavior wasn't desired.
 
Guido Sautter
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An additional issue is that Java does not allow for overloading operators (as opposed to C/C++) for a series of reasons. There's only one exception to this: the + operator for concatenating Strings. If the String class provided methods for modification, or even was non-final, the special treatment of the + operator in combination with Strings might result in unpredictable behavior.

Yet another reason is that the actual content of String constants would become mutable if Strings were mutable, with unpredicatble impact on existing code, plus a great opportunity of causing havoc in JRE native classes that use String constants.
 
Mohammed Yousuff
Ranch Hand
Posts: 198
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
as i learned The main reason why string was not made as mutable, is due to the security issue in Java.. However in Applets if some thread can change the value of String object, why can't that thread can create new String object and do the same operations?....

Can any please give me some example code so that it will be more clear... thanks ;)

 
Henry Wong
author
Marshal
Pie
Posts: 21506
84
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mohammed Yousuff wrote:as i learned The main reason why string was not made as mutable, is due to the security issue in Java.. However in Applets if some thread can change the value of String object, why can't that thread can create new String object and do the same operations?....

Can any please give me some example code so that it will be more clear... thanks ;)



Did you read EFH's example? And how does your change (create new string object and do "same operation") circumvent security?

Henry
 
Javin Paul
Ranch Hand
Posts: 295
Eclipse IDE Firefox Browser Linux
 
Stephan van Hulst
Bartender
Posts: 6327
78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not just Strings. Working with immutable classes greatly reduces overall complexity. Immutable classes are inherently thread-safe, they are more secure as mentioned earlier, you don't need to make defensive copies of them, and they are just easier to work with in general. I always strive to make as many classes immutable as I can.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic