why dont we prefer to use StringBuffer

hi,
As we know StringBuffer is better than String class, why we are not using StringBuffer in place of String class ?

They are different ways of representing String data, so the choice of when to use which depends on your circumstance.

The core difference is, I would say, that String objects are immutable whilst StringBuffer objects are mutable.

At a very simple level String is best when your data won't change. StringBuffer is best for runtime String concatenation (the compiler will take care of static concatenation thus treating as a single String). The overhead of StringBuffer creation and GC is greater than that for String, therefore StringBuffer should only be chosen when required.

A specific example would allow a more intelligent conversation than the generalisations above.

As we know StringBuffer is better than String class...

Is StringBuffer really better than String? Why?

By the way, Java 5 has a new class, StringBuilder, to replace StringBuffer. The difference between them is that StringBuilder is not synchronized, while StringBuffer is (the same difference as between the legacy collection classes Vector, Hashtable etc. and the new collection classes ArrayList, HashMap etc.).

Why does this question keep coming up? To say that one is better than the other without any context makes no sense. Is there a textbook floating around that puts the issue in those terms? If so, anyone using it should return it and demand a refund.

Originally posted by Simon Baker:
They are different ways of representing String data, so the choice of when to use which depends on your circumstance.

The core difference is, I would say, that String objects are immutable whilst StringBuffer objects are mutable.

At a very simple level String is best when your data won't change. StringBuffer is best for runtime String concatenation (the compiler will take care of static concatenation thus treating as a single String). The overhead of StringBuffer creation and GC is greater than that for String, therefore StringBuffer should only be chosen when required.

A specific example would allow a more intelligent conversation than the generalisations above.

your explanation is fine but can you please provide me an example for this?
and how can you say that overhead of StringBuffer creation and GC is greater that String?

I'd recommend the Shirazi "Java Performance Tuning" book - chapter 4 is available online and covers some of the points you raise (look at the object creation section).

As for examples, you are asking for this the wrong way round - if you provide an example of the specific usage you have where you question why we would choose String in preference to StringBuffer then people might be able to help with a concrete discussion. As other messages point out they serve different purposes. To look at a quite superficial level StringBuffer is more flexible and more resource-hungry than String. Why would you suffer the added performance overhead of the former when you don't need it's flexibility?
[ October 11, 2006: Message edited by: Simon Baker ]

A StringBuffer / StringBuilder has more features and more ways to play with your data. This is true, but it consumes memory space. If you don't need the extra features anyway, then just use String.

[saikrishna]: As we know StringBuffer is better than String class

"We" know nothing of the kind.

[Bauke]: A StringBuffer / StringBuilder has more features and more ways to play with your data.

I'd say it has different features. String has quite a few methods that StringBuffer does not share.

The most important difference, in my opinion, is immutability. By being immutable, String eliminates a number of possible errors (e.g. changing a value after you've handed a reference to it to another class), and allows for some optimizations. In general, prefer immutable objects whenever you don't have a good reason to need a mutable object. Use Strings everywhere you can, except where you need to be able to change the value. Even if you do need to change a value, various methods in String may still be useful to you. It depends what you need to do.

I wouldn't go so far as to say StringBuffer is better than String. I would say that StringBuffer and StringBuilder classes are better than String if you are doing heavy string manipulation. That's a foregone conclusion.

But, if you're just holding a reference to some basic data, using the String class is a great choice, and provides a variety of optimizations over the use of the StringBuffer class.

-Cameron Mckenzie

Originally posted by saikrishna cinux:

As we know StringBuffer is better than String class

We know nothing of the kind. Sweeping statements such as this are always wrong.

It's like saying "cheese is better than chocolate". For what?

Cheese is far superior to choclate on nachos, but it really sucks on an ice cream sundae.

Each class has its strengths for different situations.

Originally posted by Kameron McKenzie:
I would say that StringBuffer and StringBuilder classes are better than String if you are doing heavy string manipulation. That's a foregone conclusion.

Not so much even there, really. If you're doing heavy string manipulation, you're presumably concatenating Strings, and so you're using StringBuffer/Builder under the covers, anyway. The relevant question here is if you're concatenating multiple Strings, is it better to have more efficient but harder-to-read code that uses StringBuilder explicitly, or is it better to write nice clear inefficient s1 + s2 + s3.

But I hadn't commented on this thread up until now because, honestly, I didn't take it seriously. Now that all the other sheriffs are piling on, well, I guess I better say somethin'.