Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

Who r u Sting ?

 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Author
Posts: 67
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Atif Ahmed
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

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 ?
 
Ivor Horton
Author
Posts: 67
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
--Selvan
 
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Of course, I found a very beautiful couch. Definitely. And this tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic