How hard is it for you to open Docs and look it up ? it takes a second to do. No it hasn't been depricated and it will not be because for one reason of multithreading. Other wise you should always use ArrayList which is a lot faster then Vector.
Actually, you can use Collections instead of Vectors. However, you can still use Vectors, but then the problem is that, by default Vectors are synchronised & are very slow. So, it's better to use Collections.
Joined: Jan 26, 2001
Vector is considered to be a Collection just a type of List.
This question of whether Vector has been deprecated in JDK1.3 has already been answered, so I don't need to bring it up again. Cindy's comment is totally valid, but from my experience I rarely had to make use of a Vector - even in a multi-threaded environment. Here's my justification. 1. Most collections are use to hold static data from a file or database table (e.g. internal cache). 2. The collection is usually populate once - read many. If both 1 and 2 are true (which I believe is true over 90% of the time), then you should use an ArrayList. I would synchronized the method that is populating the ArrayList. After populating the ArrayList, you can use the Collections.synchronizedList(ArrayList) to get a synchronized list for reading by multiple threads. IMO, this approach is faster than using a Vector. Just $0.02, -Peter
Not really. Almost all the "extra" methods in Vector are merely trivial renaming of other methods. Well, actually it's the other methods that are renamings, since the Vector methods came first. Example: Vector has elementAt(int) method; when they built ArrayList they renamed this to get(int), and added get(int) to Vector as well even though it does the exact same thing as elementAt(int). They retained the old method name so as not to break existing code, but for new development it's easier to just use the new add(int) method for both ArrayList and Vector. Anyway, almost everything in Vector is trivial to accomplish under the ArrayList API. The only exceptions I found were: ArrayList has no constructor to set capacity increment - good, this is almost always a bad idea; exponential growth is much better. Methods: capacity() - umm, so what? indexOf(Object, int) - use subList + indexOf to mimic lastIndexOf(Object, int) - use subList + lastIndexOf to mimic setSize() - probably misunderstood by a lot of people, and not very useful anyway. What's the point of having a growable Collection if you're going to set the size? Might as well use an array in that case. [This message has been edited by Jim Yingst (edited March 21, 2001).]
"I'm not back." - Bill Harding, Twister
Joined: Feb 08, 2001
According to Peter and Jim's Analysis. It seems like we shouldn't use Vector any more.
Originally posted by Frank Carver: To expand Cindy's post - If you need your collection to be thread-safe or you don't have access to the Java 2 Collections, then use Vector, otherwise use ArrayList.
Mmmm... If you need your collection to be threadsafe, think twice before using Vector. I've seen too many greenhorns end up on the wrong side of an angry bull because they thought they were threadsafe by using a Vector. The fact that a Vector is synchronized means that multiple threads won't make a mess of your Vector. No more, no less. It does not mean that the logic you're building around the Vector is threadsafe. In fact, it usually isn't, but the Vector will lure you into thinking you're OK. And when you've finally debugged your code you will have ended up unnecessarily acquiring monitor locks twice, once in your class, once in the Vector. My recommendation would be to always use an ArrayList instead, and to carefully synchronize those actions that need synchronizing; no more, no less. - Peter