aspose file tools*
The moose likes Beginning Java and the fly likes How StringBuffer provides synchronization? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "How StringBuffer provides synchronization?" Watch "How StringBuffer provides synchronization?" New topic
Author

How StringBuffer provides synchronization?

siva chaitanya
Ranch Hand

Joined: Jul 05, 2011
Posts: 59
Please explain me with an example
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14269
    
  21

Very simple: all of its methods are synchronized.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39409
    
  28
And you rarely need synchronisation, so you usually use StringBuilder instead.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8008
    
  22

Campbell Ritchie wrote:And you rarely need synchronisation, so you usually use StringBuilder instead.

Anyone else waiting for when they actually make StringBuffer a wrapper to a StringBuilder? Or indeed, when they create an interface that includes both? Maybe the first has already been done, but I've been waiting so long for the second, I've actually created my own (called StringHolder). Sheesh, software companies are dumb sometimes.

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
I would rather they just got rid of StringBuffer entirely. No need to keep the interfaces polluted with a useless class. If you need synchronization, you need it in a different place than what StringBuffer provides.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39409
    
  28
I take your point, Mike S, but if you remove a class, then all the legacy code which depended on it is broken. It does say clearly in its documentation you ought to prefer StringBuilder, but so many people never seem to read that bit.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Yes, it would be a backward-incompatible change. Java is overdue for one of those, really - there's a lot of cruft that could be cleaned out, that Sun was never willing to ditch. I'm hoping Oracle will be more willing.

Having said that, like Winston I am surprised that they didn't retrofit a common interface onto StringBuilder/StringBuffer when Builder was introduced. Especially since it was Sun at the time. Oh well...
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39409
    
  28
There are lots of things they should have done, like creating a Stack interface …
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Yeah - but most of those things, like Stack, are legacy things from Java 1.0 or 1.1. I'd grown used to Sun not touching that stuff for fear of breaking legacy code. But introducing StringBuilder came in 1.5, when Sun had much better design practices. Right then was the time to introduce a common interface, as they did for other API enhancements. Don't know why they didn't.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8008
    
  22

Mike Simmons wrote:Yeah - but most of those things, like Stack, are legacy things from Java 1.0 or 1.1.

The fact is that what I suggested is not a legacy problem. It might, however, be a political problem.

@Java: Define a public interface in java.lang that implements ALL the methods of both classes (and there are LOTS of them; and they're already documented as being in sync), and put it in Version 8; and make both StringBuffer and StringBuilder implement it.

Most of us experienced bods know that that's what you should have done in the first place. So get on with it. If you don't want to apologise for all the problems that have been caused by having both a StringBuffer and StringBuilder class that do exactly the same thing, at least give us the chance to refactor our programs to use a standard interface.

Winston
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18657
    
    8

So... would this new interface be a sub-interface of CharSequence, which StringBuffer and StringBuilder both already implement, or would it be separate?
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Subinterface. We want all those mutator methods as well; that's the point of having a StringBuffer/Builder. We might as well extend CharSequence since that's already part of the basic functionality.

The other issue is the various methods elsewhere that take a StringBuffer as argument. Like in java.util.regex.Matcher. Changing those signatures could create problems; they'd probably have to add overloads. Ugh. I think I'm back to wanting them to get rid of StringBuffer entirely, and force everyone else to deal with it.
Ivan Jozsef Balazs
Rancher

Joined: May 22, 2012
Posts: 867
    
    5
Winston Gutkowski wrote:
Or indeed, when they create an interface that includes both?


Like this?

java.lang
Interface Appendable
Since: 1.5

Known Implementing Classes include StringBuffer, StringBuilder
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Kind of. But we were imagining a much less crappy version of that.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14269
    
  21

Mike Simmons wrote:I would rather they just got rid of StringBuffer entirely. No need to keep the interfaces polluted with a useless class.

There are a lot of other things in the standard Java API that would better be removed. For example the legacy collection classes such as Vector, Hashtable, Dictionary; Enumeration, the Date and Calendar classes (those should be replaced by something like Joda Time), the org.omg.* packages (for CORBA), etc. It's however not going to happen because it would break too many existing programs.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
I'm dreaming of a day when all that stuff is removed. Or most of it, anyway. I think Oracle is more capable of envisioning a major change like this than Sun was. It may still be a long shot, but I think it's possible.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14269
    
  21

To avoid going too much off topic, I started a new thread about that: Should old stuff be removed from a future Java version?
 
 
subject: How StringBuffer provides synchronization?