It's not a secret anymore!*
The moose likes Beginning Java and the fly likes String Vs StringBuffer Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "String Vs StringBuffer" Watch "String Vs StringBuffer" New topic
Author

String Vs StringBuffer

Abhijeet Deshmukh
Greenhorn

Joined: Aug 09, 2004
Posts: 6
hi,

what is difference bet String and StringBuffer objects.
Mattias Arthursson
Ranch Hand

Joined: Jul 26, 2004
Posts: 90
The main difference is that a StringBuffer is mutable, whereas a String is not. That is, once a String object has been created it can't be modified later. This means that when you want to perform a lot of String concatenation and stuff like that you probably should consider using a StringBuffer in stead of String objects.


Admit nothing. Blame everyone. Be bitter.
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
For further explanation on the topic of mutable and immutable objects, I'd recommend taking a look at David O'Meara's JavaRanch Journal article, "Mutable and Immutable Objects".


[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
Rick Portugal
Ranch Hand

Joined: Dec 17, 2002
Posts: 243
By the way, the new version of Java, J2SE 5 ("Tiger"), also has a StringBuilder class. It is like StringBuffer only faster.


IBM 286, SCJP, SCWCD, EIEIO
Mahesh Bhatt
Ranch Hand

Joined: Sep 15, 2004
Posts: 88
thats correct ...rick and dirk have said it .... if u still have doubts in the differences b/w String and StringBuffer u might actually try this out ...

go to the DOS and type : javap java.lang.String

and then type : javap java.lang.StringBuffer ...these commands will telll u all the methods defined in these classes ... and if u notice carefully u can see that StringBuffer has got more functions than String has.... look at the "delete" kind of methods ...these will tell u the fact that String is immutable ...and StringBuffer is not ......


Impossible is I M Possible
Mahesh Bhatt
Ranch Hand

Joined: Sep 15, 2004
Posts: 88
however .....anyone out there who can tell me this IMMUTABLE thing in a easy to understand way .... i dont get one thing ...when strings are immutable ...then y r they changed when u do concatination or use + operator on it
Eric Fletcher
Ranch Hand

Joined: Oct 26, 2000
Posts: 188
Originally posted by prashant bhogvan:
however .....anyone out there who can tell me this IMMUTABLE thing in a easy to understand way .... i dont get one thing ...when strings are immutable ...then y r they changed when u do concatination or use + operator on it


Because behind the scenes the JVM is creating a StringBuffer and appending the String you are concatinating to the original String. It then assigns the Original String reference to the toString returned form the String buffer. So


Is, under the covers, actually equivalent to:



Hope that helps. Incidentally, this is also the reason for the popular performance tip to use StringBuffers instead of using concatenation, especially for a long sequence of concats. Since the JVM has to create a new StringBuffer for each concat operator, might as well take the extra steps and create and append on your own since you will only create one.

E


My theory of evolution is that Darwin was adopted. - Steven Wright
Simon Baker
Ranch Hand

Joined: Sep 09, 2004
Posts: 57
The important thing to remember is that:

line 1: String a = "1";
line 2: String b = "2";
line 3: a += b;

causes the String object referenced by "a" to be dereferenced at line 3, and so eligible for garbage collection (which can be seen as a delayed overhead) and a new String object, to which "a" is pointed, gets created.

line 1: StringBuffer a = new StringBuffer("1");
line 2: String b = "2";
line 3: a.append(b);

causes the StringBuffer object referenced by "a" to be changed at line 3, not requiring the creation of any new objects.

The difference is down to the mutability of the StringBuffer object, and the immutability of the String object (mutable = capable of change).

In addition, don't get confused by the advice to use StringBuffer for performance.

In practise the advice to use StringBuffer only holds when concatenated items are only resolvable at runtime, and not compile time (as per the example in the previous entry to this thread).

e.g.

String myDynamicString = ...(some dynamic value)...
...
String myConcatenatedString = "This is the String: " + myDynamicString;

the above would cause the creation of 2 String objects at the line creating myConcatenatedString. A possible exception to this is that the static String reference will reuse an existing String instance if the same static String has already been used.

Performing the above using a StringBuffer avoids the creation of the extra String.

But:

String myConcatenatedString = "This is the String: " + "here it is";

will not result in an extra String object since the compiler will resolve the above to a single String (possible because both Strings are static). Thus, there is no performance loss in splitting a static String across multiple lines for readability.

Also note that the StringBuffer causes it's own overhead and so for a small number of concatenations might make things slower than creating an extra String object anyway. It might not - you'd need to test to check this.
Eric Fletcher
Ranch Hand

Joined: Oct 26, 2000
Posts: 188
Originally posted by Si Brewster:


In addition, don't get confused by the advice to use StringBuffer for performance.

In practise the advice to use StringBuffer only holds when concatenated items are only resolvable at runtime, and not compile time (as per the example in the previous entry to this thread).

e.g.

String myDynamicString = ...(some dynamic value)...
...
String myConcatenatedString = "This is the String: " + myDynamicString;

the above would cause the creation of 2 String objects at the line creating myConcatenatedString. A possible exception to this is that the static String reference will reuse an existing String instance if the same static String has already been used.

Performing the above using a StringBuffer avoids the creation of the extra String.

But:

String myConcatenatedString = "This is the String: " + "here it is";

will not result in an extra String object since the compiler will resolve the above to a single String (possible because both Strings are static). Thus, there is no performance loss in splitting a static String across multiple lines for readability.

Also note that the StringBuffer causes it's own overhead and so for a small number of concatenations might make things slower than creating an extra String object anyway. It might not - you'd need to test to check this.


Just to be clear, avoiding the creation of extra String objects is not the primary efficiency gain from using StringBuffer vs. the concatenation operator. The gain is in the overhead cause by the behind-the-scenes creation of StringBuffers by the JVM for each contcatenation. Here is a
link that demonstrates that.

You are correct in pointing out that unless you are doing a relatively long sequence of concatenations, the performance gain is probably minimal.

In any event, I'm of the opinion that Strings are immutable, StringBuffers are not, therefore when I need a mutable String, I tend to use StringBuffers as opposed to concatenating Strings.

E
[ September 16, 2004: Message edited by: Eric Fletcher ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: String Vs StringBuffer
 
Similar Threads
byte [ ] to StringBuffer
classcastexception
How many Object is created?
StringBuffer and String returned from a method doubt
StringBuffer question