This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
It is, technically, in the sense that each method individually is thread-safe. However it's difficult to accomplish anything useful with this class without some additional synchronization. For example when iterating, you need to synchronize, as shown here. Yes, that discussion is for Collections.synchronizedList(), but Vector works the same way. The basic problem is that while each individual method call is synchronized, nothing prevents other threads from inserting other method calls in between two calls that really need to go together. If you've just made a call to iterator.hasNext() and it returned true, can you safely call iterator.next()? Not without extra synchronization - because how do you know that some other thread didn't remove() or clear() the next item, immediately after you called hasNext()? In general, you don't. There are other examples where Vector and synchronizedList() usage require additional synchronization, but iteration is the most common.
My own opinion is that the synchronization in Vector and Collections.synchronizedList() is close to useless, and dangerously misleading. You're usually better off synchronizing on the list externally, using synchronized blocks. Or writing the code in a way that no synchronization is required at all.
Joined: Jun 27, 2008
Thank you very much for your detailed explanation. I will use locks.