Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

String >StringBuffer  RSS feed

 
Daniel .J.Hyslop
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In this program I declare and initialise a String , then in a println statement I change it to uppercase, when I print the same variable after this it appears not to have changed from the initial initialisation.After I have declared and initialised the StringBuffer ,I carry out the same test in the println st--nt I reverse the StringBuffer value, when I print this variable after that ,it has kept the new value. Could someone explain please? Strings are immutable ,StringBuffers can be modified.When this code is run how are those properties affecting the variables in these different ways


Thankyou Danny
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As you noted, Stings are immutable, but StringBuffers can be changed. The key point (I think) is in understanding the following line...

Here, a new String object is created by the call s1.toUpperCase(), and that new String is assigned to the variable s1. The String that s1 was previously pointing to hasn't changed at all -- it's just that s1 is no longer pointing to it.
[ August 17, 2005: Message edited by: marc weber ]
 
Norm Radder
Ranch Foreman
Posts: 2240
28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you read the doc for the String.toUpperCase() method you'll see that it RETURNS a String. That returned value must be assigned to a variable otherwise its lost forever. EG s1 = s1.toUpperCase() // as described above.
In general its useful to read the doc when you're using a method or class that you're not sure of.
 
Daniel .J.Hyslop
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Marc,
That part I understand, the main point I would like defined is

String s1 = new String("Danny");

System.out.println("s1 = " + s1.toUpperCase());//prints DANNY
System.out.println("s1 = " + s1);//prints Danny - hasn`t been changed

In this scenario the first println prints out what I would expect Danny is now in uppercase "DANNY", when the variable is printed in the second print statement no change is visible, the original value is still present as the new value was`nt assigned to it



StringBuffer sb = new StringBuffer("Danny");// value passed Danny

System.out.println("sb " + sb.reverse());//reverse sb prints "ynnad"
System.out.println( sb );//prints ynnad value has been changed ?

In this scenario the original String is Danny passed to the StringBuffer constuctor ,The first println changes the StringBuffer variable using the reverse method, when the variable is printed to screen in the second println statement the new value has been retained, unlike the previous String variable example .The String variable has not changed because of the reasons expressed previously and yet the StringBuffer has ?
Thanks
[ August 17, 2005: Message edited by: Daniel .J.Hyslop ]
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Daniel .J.Hyslop:
... The String variable has not changed because of the reasons expressed previously and yet the StringBuffer has?

Exactly. StringBuffers are mutable, and the reverse method actually replaces the char sequence in the buffer.
 
Ryan Kade
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Daniel .J.Hyslop:
The String variable has not changed because of the reasons expressed previously and yet the StringBuffer has ?
Thanks


The thing to remember is, calling s1.toUpperCase (when s1 is referencing a String) NEVER changes s1. Ever. In fact, calling s1.<anything> never changes s1. s1 always remains exactly the same as when you first created it until you reassign it to something else. That's what immutability is.

StringBuffers are different -- they operate like you are expecting.
 
Periakaruppan Thiagarajan
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
Do you know why Strings are made immutable in Java ?.
"One of the key goals of any good programming language is to make efficient use
of memory. As applications grow, it�s very common that String literals occupy large
amounts of a program�s memory, and that there is often a lot of redundancy within
the universe of String literals for a program. To make Java more memory efficient,
the JVM sets aside a special area of memory called the �String constant pool.� When
the compiler encounters a String literal, it checks the pool to see if an identical String
already exists. If a match is found, the reference to the new literal is directed to the
existing String, and no new String literal object is created. (The existing String
simply has an additional reference.) Now we can start to see why making String
objects immutable is such a good idea. If several reference variables refer to the same
String without even knowing it, it would be very bad if any of them could change
the String�s value.
You might say, �Well that�s all well and good, but what if someone overrides the
String class functionality; couldn�t that cause problems in the pool?� That�s one of
the main reasons that the String class is marked final. Nobody can override the
behaviors of any of the String methods, so you can rest assured that the String objects
you are counting on to be immutable will, in fact, be immutable.
"
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Periakaruppan, I believe there's a copyright on that page, so you might want to at least cite the source.

http://www.54bk.com/more.asp?name=zhp54321&id=2069
 
Daniel .J.Hyslop
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks everyone , all info has been very helpfull
 
kenji mapes
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"One of the key goals of any good programming language is to make efficient use
of memory.


Yeah, but ins't there a tradeoff there too? E.G. with things such as sorting an array? You might save more time, memory, or what have you, but there is still a cost, no?

Also, is memory such a concern when more and more people have more memory in their systems as opposed to say 5 years ago? How many devs consider it a prime concern?
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!