Win a copy of Head First Android this week in the Android forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

Difference between Stringbuilder and Stringbuffer class

 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hello everyone,
upto theory i come to know stringbuffer is a synchronized class (i.e thread safe ) while Stringbuilder is not.
even all the function applied on both the class are same
let me know about the best example through which we can differentiate both the class
please help
 
Rancher
Posts: 43027
76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Write a class that creates a number of threads that all manipulate the same StringBuffer instance concurrently.
 
Marshal
Posts: 74354
334
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

sparsh khandelwal wrote: . . . stringbuffer is a synchronized class (i.e thread safe ) . . .

Are we sure StringBuffer is thread‑safe?
I usually use such objects as local variables, where threading issues do not apply.
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:

sparsh khandelwal wrote: . . . stringbuffer is a synchronized class (i.e thread safe ) . . .

Are we sure StringBuffer is thread‑safe?



Indeed. There's no such thing as a "synchronized class," but if we take it to mean "a class, all of whose non-private methods are synchronized," then, okay, fine, we can call it that.

The real issue though is that making every method synchronized does not make the class "thread-safe," at least not in the sense that I think a lot of people assume it does. It's trivially easy to use such a class in a thread-unsafe way. For instance, with StringBuffer, if I call sb.append("a").append("b") in 2 threads simultaenously, I could end up appending "aabb" or "abab".


I usually use such objects as local variables, where threading issues do not apply.



Me too. I never really understood the point of StringBuilder. By the time it came out, unconstested synchronization had become quite fast, and you wouldn't use it in a case where the synchronization could be contested, so where's the benefit?. And I don't think I've ever in 15 years of Java programming used a StringBuffer/Builder in a situation where thread safety was an issue anyway, so, again, it seems like there's really no point in it. Granted, it was a trivially easy class to create, but still.
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jeff Verdegan wrote:Me too. I never really understood the point of StringBuilder ... And I don't think I've ever in 15 years of Java programming used a StringBuffer/Builder in a situation where thread safety was an issue anyway, so, again, it seems like there's really no point in it.


Don't you mean the opposite - what's the point of StringBuffer? StringBuilder is what StringBuffer should have been; it's StringBuffer without the synchronization that nobody needs. There was no point in synchronizing StringBuffer, because nobody uses it from multiple threads concurrently. Unfortunately StringBuffer isn't going to be removed because of backward compatibility reasons, even worse, it's not even going to become deprecated, because Oracle is afraid that it would annoy too many people who have been using StringBuffer all the time in their source code with deprecation warnings.

Anyway, the point is: Forget about StringBuffer. Always use StringBuilder instead.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesper de Jong wrote:

Jeff Verdegan wrote:Me too. I never really understood the point of StringBuilder ... And I don't think I've ever in 15 years of Java programming used a StringBuffer/Builder in a situation where thread safety was an issue anyway, so, again, it seems like there's really no point in it.


Don't you mean the opposite - what's the point of StringBuffer? StringBuilder is what StringBuffer should have been;



No, I meant what's the point in StringBuilder.

True, the syncing in Buffer was pointless. But it also was harmless, at least by the time Builder came along. So once all that code is out there using Buffer, why bring in Builder to address a tiny design flaw that has no real consequences?

Anyway, the point is: Forget about StringBuffer. Always use StringBuilder instead.



Yeah, now that it's there, we might as well use it.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic