• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

why dont we prefer to use StringBuffer

 
saikrishna cinux
Ranch Hand
Posts: 689
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,
As we know StringBuffer is better than String class, why we are not using StringBuffer in place of String class ?
 
Simon Baker
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15452
42
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.).
 
Alan Moore
Ranch Hand
Posts: 262
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
saikrishna cinux
Ranch Hand
Posts: 689
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Simon Baker
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Bauke Scholtz
Ranch Hand
Posts: 2458
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[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.
 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65126
92
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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'.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic