wood burning stoves 2.0*
The moose likes Java in General and the fly likes string vs stringbuffer Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "string vs stringbuffer" Watch "string vs stringbuffer" New topic
Author

string vs stringbuffer

Ashwini Surve
Greenhorn

Joined: Feb 13, 2012
Posts: 1
what is the difference between string and stringbuffer in java??
Swastik Dey
Rancher

Joined: Jan 08, 2009
Posts: 1449
    
    6

Immutable and mutable.


Swastik
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38006
    
  22
Welcome to the Ranch

You are obviously reading an old book; you ought not to use StringBuffer, but StringBuilder in most cases. Please be careful about spellings; the capital S is significant.
Have you read their API documentation? It is quite clear.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Ashwini Surve wrote:what is the difference between string and stringbuffer in java??


http://docs.oracle.com/javase/6/docs/api/java/lang/String.html
http://docs.oracle.com/javase/6/docs/api/java/lang/StringBuffer.html
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Campbell Ritchie wrote:Welcome to the Ranch

You are obviously reading an old book; you ought not to use StringBuffer, but StringBuilder in most cases.


I never got that. I know Builder is not synchronized, and therefore "faster", but uncontested lock acquisition has been fast since before Builder came into existence.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38006
    
  22
So many people post as if they had only seen StringBuffer and never StringBuilder. There must be people reading JDK1.4 books still.
And the recommendation to use StringBuilder comes from its API documentation, and there is a similar recommendation in the StringBuilder docs.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19653
    
  18

Oracle should fix some of their own API to reflect that though. I'm a bit annoyed that java.util.regex.Matcher hasn't had its appendReplacement and appendTail methods overloaded to also take a StringBuilder.

What I'm even more annoyed about is that Sun at the time introduced a new super class of StringBuffer, java.lang.AbstractStringBuilder, but chose to make it non-public. Right now library classes often have to make a choise between StringBuilder and StringBuffer, or require overloading to accept both:
Had they made AbstractStringBuilder public then you could have instead written this:


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Campbell Ritchie wrote:So many people post as if they had only seen StringBuffer and never StringBuilder. There must be people reading JDK1.4 books still.
And the recommendation to use StringBuilder comes from its API documentation, and there is a similar recommendation in the StringBuilder docs.


Yeah, I get all that. I'm just wondering why Builder came into existence in the first place. I can't imagine a real-world, uncontested situation where Buffer's syncing would cause a problem. Maybe in JME or something?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

Jeff Verdegan wrote:I can't imagine a real-world, uncontested situation where Buffer's syncing would cause a problem.


It may not cause any technical problem, but the real world still seems to be full of people who are basing their judgments on web pages and urban legends from somewhere around 1999. These people are convinced that synchronization is slow and that creating an object should be avoided, just for example.

That's also why they don't appear to have heard of StringBuilder -- presumably their textbook, or the syllabus of the school they're attending, also hasn't been updated since then.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18523
    
  40

Jeff Verdegan wrote:
Campbell Ritchie wrote:
You are obviously reading an old book; you ought not to use StringBuffer, but StringBuilder in most cases.


I never got that. I know Builder is not synchronized, and therefore "faster", but uncontested lock acquisition has been fast since before Builder came into existence.


I think they came around the same time. The huge performance gains regarding uncontested lock grabs appeared with Java 5 -- which also saw the appearance of the StringBuilder class.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Darryl Burke
Bartender

Joined: May 03, 2008
Posts: 4523
    
    5

Jeff Verdegan wrote:I can't imagine a real-world, uncontested situation where Buffer's syncing would cause a problem. Maybe in JME or something?


Java ME doesn't even have a StringBuilder. There's only StringBuffer.
http://docs.oracle.com/javame/config/cldc/ref-impl/midp2.0/jsr118/java/lang/package-summary.html


luck, db
There are no new questions, but there may be new answers.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Henry Wong wrote:
Jeff Verdegan wrote:
Campbell Ritchie wrote:
You are obviously reading an old book; you ought not to use StringBuffer, but StringBuilder in most cases.


I never got that. I know Builder is not synchronized, and therefore "faster", but uncontested lock acquisition has been fast since before Builder came into existence.


I think they came around the same time. The huge performance gains regarding uncontested lock grabs appeared with Java 5 -- which also saw the appearance of the StringBuilder class.

Henry


That may make a little more sense then. If they were initiated independently, or if people weren't sure how good the sync improvements would really be.

Maybe.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2993
    
    9
On the other hand, it's extremely rare that StringBuffer's synchronization actually achieves anything useful. And on the rare occasions that a StringBuffer instance is accessible to multiple threads, it's probably not good enough to just rely on method synchronization. You would usually need additional synchronization to prevent another thread interjecting a method call while you're composing a message. So I would argue that StringBuffer's synchronization is harmful by virtue of encouraging people to think the class is "thread-safe" when it really isn't. (Much like most of Sun's other "thread-safe" classes, before java.util.concurrent came out.) In my opinion, we would be better off if they'd gotten rid of the synchronization entirely.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38006
    
  22
Mike Simmons wrote: . . . if they'd gotten rid of the synchronization entirely.
Which brings us back to StringBuilder
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2993
    
    9
Yes, except that StringBuffer still exists, with synchronization, giving the impression that it serves a useful function somewhere. Which it does not.

Realistically, Sun would never just get rid of such a class, or remove the synchronization after it had been documented like that. But they could have at least deprecated StringBuffer when StringBuilder was introduced.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7545
    
  18

Mike Simmons wrote:Yes, except that StringBuffer still exists, with synchronization, giving the impression that it serves a useful function somewhere. Which it does not.

Realistically, Sun would never just get rid of such a class, or remove the synchronization after it had been documented like that. But they could have at least deprecated StringBuffer when StringBuilder was introduced.

Weirdly enough, I've created a StringHolder interface (edit: not the one you get if you click on it, obviously) that can accept either one to wrap. Took a while, but I've never looked back since. I wonder if I could sell it to Oracle?

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38006
    
  22
If that abstract class Rob mentioned earlier had been an interface instead, that would have been sorted ages ago.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2993
    
    9
Well, if it had been a public interface, yes. Or if it had been a public class, as Rob said. Either way, the problem is that it's not public, not that it isn't an interface.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: string vs stringbuffer
 
Similar Threads
byte [ ] to StringBuffer
classcastexception
How many Object is created?
StringBuffer and String returned from a method doubt
StringBuffer question