Real world Examples for StringBuffer and StringBuilder.

[datta Nadgir]

A big Hello to all JavaRanch fans, This is my first post and I'm happy. coming to question, Please tell me any real world examples for StringBuilder and StringBuffer and clarify me in which scenarios i should use these , I've read about these in many textbooks, but I get only "thread safe", but not any real world example. help is needed and thanks in advance !!!

[Paul Clapham]

In real-world situations you should use StringBuilder now. The scenarios where you would want to use StringBuffer because the methods are synchronized are extremely unlikely -- I can't envisage anybody ever wanting to use multiple threads trying to operate on a StringBuffer simultaneously.

[Paul Clapham]

And, welcome to the Ranch!

[Campbell Ritchie]

I gave an example yesterday: look here.

And welcome, again.

[datta Nadgir]

Paul Clapham wrote:In real-world situations you should use StringBuilder now. The scenarios where you would want to use StringBuffer because the methods are synchronized are extremely unlikely -- I can't envisage anybody ever wanting to use multiple threads trying to operate on a StringBuffer simultaneously.

A tonne of thanks,

[Rob Spoor]

The only times I actively use StringBuffer is when working with java.util.regex.Matcher or java.text.Format - because their APIs force me to. I'd love to see updates to those classes to accept StringBuilder, but I know that Format won't get it - since one of the methods that accepts StringBuffer is abstract, there is no logical implementation for it and adding it as a new abstract method breaks a lot of code (existing sub classes not part of the JSE API).

[Campbell Ritchie]

I thought Matcher and Pattern were both final.
Might it be worth requesting an update for Matcher to accept a StringBuilder?

[Winston Gutkowski]

Rob Spoor wrote:I'd love to see updates to those classes to accept StringBuilder...

Actually, I'd love to see an interface that encapsulates both; since their APIs are identical. Then all you'd need to do it to retrofit it into places where it makes sense.

I've actually written one myself, and it works great; but it was darn verbose because I don't have access to the original classes - and those suckers have LOTS of methods (far too many in my opinion).

Quick question: How many people here still use String when CharSequence would probably be better?

Winston

[Rob Spoor]

Campbell Ritchie wrote:I thought Matcher and Pattern were both final.
Might it be worth requesting an update for Matcher to accept a StringBuilder?

They are final, so for Matcher it wouldn't be too hard to add the method. I just never bothered to request it. I also doubt they would add it, as there is quite some code involved for the methods that use StringBuffer. For reference, appendReplacement is 98 lines (excluding method signature and closing }). The others aren't a problem, but I doubt Oracle would want to copy those 98 lines of logic.

Winston Gutkowski wrote:

Rob Spoor wrote:I'd love to see updates to those classes to accept StringBuilder...

Actually, I'd love to see an interface that encapsulates both; since their APIs are identical. Then all you'd need to do it to retrofit it into places where it makes sense.

I've actually written one myself, and it works great; but it was darn verbose because I don't have access to the original classes - and those suckers have LOTS of methods (far too many in my opinion).

There actually is a common super class - java.lang.AbstractStringBuilder. However, it's not public, and I honestly don't see a reason why. Making it public wouldn't break anything (reflection still finds the class), the only reason would be to the class hierarchy of StringBuffer consistent between 1.4 and 5.0. Which is a rubbish reason if reflection can find it anyway.

Quick question: How many people here still use String when CharSequence would probably be better?

I've actually rewritten some parts of my code recently to accept CharSequence where it first accepted String. The class is still called Strings though