File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Beginning Java and the fly likes Who r u Sting ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Who r u Sting ?" Watch "Who r u Sting ?" New topic

Who r u Sting ?

Atif Ahmed

Joined: Mar 21, 2002
Posts: 21
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.
Ivor Horton
Ranch Hand

Joined: Mar 22, 2002
Posts: 67
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="" target="_blank" rel="nofollow">Beginning Java 2 SDK 1.4 Edition</a>
Atif Ahmed

Joined: Mar 21, 2002
Posts: 21

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.
In Other word why String Object is immutable ?
Ivor Horton
Ranch Hand

Joined: Mar 22, 2002
Posts: 67
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.
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
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,
[ March 26, 2002: Message edited by: Corey McGlone ]

SCJP Tipline, etc.
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
It ios done for efficiency purposes. Strings are widely used and therefore they must be as efficient as possible. That is also the reason that the String class is final.

Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Selvan tiru

Joined: Jul 12, 2001
Posts: 18
The s.concat is creating a new String by appending. May be Since "new" key word is not
used here, it may be confusing to think that
concatenated string is entirely
new and different object.
Jorge Phillips
Ranch Hand

Joined: Jun 03, 2001
Posts: 43
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 agree. Here's the link:
subject: Who r u Sting ?
jQuery in Action, 3rd edition