String Vs StringBuffer

hi,

what is difference bet String and StringBuffer objects.

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.

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".

By the way, the new version of Java, J2SE 5 ("Tiger"), also has a StringBuilder class. It is like StringBuffer only faster.

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 ......

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
String s = "First Part"; s + ":Second Part";

Is, under the covers, actually equivalent to:

String s = "First Part"; StringBuffer buffer = new StringBuffer(s); buffer.append(":Second Part"); s = buffer.toString();

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

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.

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 ]