I think you are rather exaggerating what that blog says, but it explains how using a StringBuffer in two threads can result in unpredictable behaviour. But that is a rather contrived situation designed to produce unpredictable results. That is why many people nowadays hardly use StringBuffer. The StringBuffer API documentation is reasonably clear about it.
I suddenly get a new thought here. So assumed that making the string buffer synchronized was of no use which they realized in java 1.5 and going by same idiom we have vector.
Here is the text from Java Concurrency in Practise If synchronization is the cure for race conditions, why not just declare every method synchronized? It turns out that such indiscriminate application of synchronized might be either too much or too little synchronization. Merely synchronizing every method, as Vector does, is not enough to render compound actions on a Vector atomic:
if (!vector.contains(element)) vector.add(element);
This attempt at a put-if-absent operation has a race condition, even though both contains and add are atomic. While synchronized methods can make individual operations atomic, additional locking is requiredwhen multiple operations are combined into a compound action. (See Section 4.4 for some techniques for safely adding additional atomic operations to thread-safe objects.) At the same time, synchronizing every method can lead to liveness or performance problems, as we saw in SynchronizedFactorizer.
Now does that mean anything under Collections framework was inadequately designed ?
A true question that struck me and I am not pin pointing something
In the design of Java 1.0 with StringBuffer and Vector, the designers were very cautious. Subsequent evolution led to additional solutions but the original classes are still there to provide continuity.
[Bill]: In the design of Java 1.0 with StringBuffer and Vector, the designers were very cautious.
Hm, I think that's being overly generous. Despite being "cautious" they designed APIs that are not, generally, safe to use with multiple threads (without additional synchronization) yet described them as "thread-safe". A dangerously misleading idea, I think.
[Santhosh]: Now does that mean anything under Collections framework was inadequately designed ?
Well, the objects returned by Collections.synchronizedList() and other synchronizedXXX() methods are just as flawed as Vector is. They do document that the Iterator requires external synchronization in order to be safe, which is an improvement over the original Vector. But they fail to make the same point about any other set of compound actions you might want to perform on a mutable collection. And they continue to use the term "thread-safe" to mislead young programmers into thinking that they're, well, safe in using multiple threads with this class.
[Campbell]: But that is a rather contrived situation designed to produce unpredictable results.
Mmmm, I think it's not contrived at all. Unpredictable behavior is pretty easy to find if you're accessing a StringBuffer from multiple threads without external synchronizaztion. I'd have to work harder to imagine a realistic scenario where it's not an issue. Maybe if no threads ever remove any characters, or if only one thread removes (and other operations) while all the other threads can only append new data. But in any situation where one thread may remove one or more characters while another thread tries to read them, you need some sort of external synchronization to handle the situation safely. That, or you need to be willing to catch some sort of IndexOutOfBoundsException to handle what happens when data is deleted just as you try to read it. Ugh.
In short, while I can't say that the synchronization in StringBuffer and Vector is completely useless, I think it's pretty darned close to useless. And more importantly, it's dangerously misleading to other programmers, who usually need more synchronization in order to be safe. Which is worse than useless, in my mind. I say, do not trust any class that's labeled as "thread-safe" - Sun has badly misused this term over the years. Though I do approve of later classes like ConcurrentHashMap, which provide more useful methods, and document their limitations better.
If tomatoes are a fruit, then ketchup must be a jam. Taste this tiny ad:
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth