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.
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...
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.
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.
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.