File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

String Vs StringBuffer

 
Abhijeet Deshmukh
Greenhorn
Posts: 6
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,

what is difference bet String and StringBuffer objects.
 
Mattias Arthursson
Ranch Hand
Posts: 90
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Dirk Schreckmann
Sheriff
Posts: 7023
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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".
 
Rick Portugal
Ranch Hand
Posts: 243
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By the way, the new version of Java, J2SE 5 ("Tiger"), also has a StringBuilder class. It is like StringBuffer only faster.
 
Mahesh Bhatt
Ranch Hand
Posts: 88
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ......
 
Mahesh Bhatt
Ranch Hand
Posts: 88
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 188
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Simon Baker
Ranch Hand
Posts: 57
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 188
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic