Hi We know String object changed its memory location when we add some thing in it & Sting Buffer not. Can any one Tell me why String Object change its memory location when we add some thing in it. Thanks
String objects are immutable - in other words, once you create a String object it ca never be changed. When you add something to a String object what actually happens is that a new String object is created than encapsulates the modified string. Of course, this object will be at some other address. A StringBuffer object encapsulates a string that you can change. So when you append something to it or otherwise change it, you are modifying the existing object.
Ivor Horton<br />Author of the Beginning Java Series including the new <a href="http://www.amazon.com/exec/obidos/ASIN/1861005695/ref=ase_electricporkchop" target="_blank" rel="nofollow">Beginning Java 2 SDK 1.4 Edition</a>
Joined: Mar 21, 2002
Thanks Ivor. I know that all . My Question is that why we feel that we give new memory location to a string object when it change & not do same thing in String Buffer case. or In Other word why String Object is immutable ?
Joined: Mar 22, 2002
The simple answer is that a String object is immutable because the Java folks made it that way. They called the object that encapsulates a mutable string a StringBuffer object. If you are asking why you need to encapsulate an immutable string, I suppose the answer is efficiency. If the string is immutable, the class does not have to carry around all the baggage necessary to change it so the class is smaller and faster. If you use string interning with String objects, you can do fast compares using == instead of equals(). This is only possible with immutable objects.
Try not to think of it as giving a String object a new memory location. That's not really what has happened. Rather, we've created a new String object that has a different memory location. The original String is still right where it was before. Take the following code example:
We first create a String with the contents "Hello" on the heap and assign a reference to it to s. Next, we call the concat method, which creates a new String object and assigns the reference to that String to s. The original String, "Hello" is just where it always was and will remain there until the program terminates. We haven't changed the location, but, rather, created a new object at a different location. I believe the reason String was made immutable was for efficiency reasons. I'm not sure about that, though. I hope that helps, Corey [ March 26, 2002: Message edited by: Corey McGlone ]
The concept of immutable strings arose way back when issues like reentrant or pure code became very important in time-shared systems to optimize memory utilization. A string pool could be packed efficiently in a single segment or file, and a specific string could be denoted by its address in the pool (think C!). Multiple users could share the string pool simultaneously. String operations(concatenation, substitution, etc) implemented on top of string pools would return their results as new strings added at the end of the pool. I am quite sure these "best practices" must have influenced Java language designers when deciding on string datatype implementations for the JVM. The immutable representation is not space efficient, as there is no string reuse, a problem which they easily solved through string buffer encapsulation. [ March 28, 2002: Message edited by: Jorge Phillips ]
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com