string vs stringbuffer

what is the difference between string and stringbuffer in java??

Immutable and mutable.

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.

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

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.

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.

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-coderanch. Right now library classes often have to make a choise between StringBuilder and StringBuffer, or require overloading to accept both:
public StringBuffer doSomething(StringBuffer sb) { ... } public StringBuilder doSomething(StringBuilder sb) { ... }Had they made AbstractStringBuilder public then you could have instead written this:
public <SB extends AbstractStringBuilder> doSomething(SB sb) { ... }

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?

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.

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

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

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.

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.

Mike Simmons wrote: . . . if they'd gotten rid of the synchronization entirely.

Which brings us back to StringBuilder

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.

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

If that abstract class Rob mentioned earlier had been an interface instead, that would have been sorted ages ago.

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 coderanch, not that it isn't an interface.