where's your Vector, victor

I read that the Vector class is obsolete.

Can someone tell me in a nutshell why this is so?

Thank you.

 

Same as with Hashtable.
It's all synchronized, = slow.
And to make things worse, returned iterators are not synchronized
So, either pick some unsynchroized from java.util, or go to
java.util.concurrent.

Regards...

 

Because ArrayList has the same capabilities without the pointless overhead
of the internal synchronization of Vector. Since it turned out that that
synchronization is not enough to make Vector thread-safe, there is no sane
reason to use it. The same is true for Hashtable: it has the overhead of
thread safety, but isn't really thread safe, so use HashMap instead.

Liebe Gruesse,
Joerg

 

One or the other of these arguments might be relevant, but
they can't both be relevant at the same time.

 

Mostly mythology. The Vector provides some additional functionality
over a synchronized List but it's probably not something you will need.
If you don't need any synchronization then use an ArrayList, if you do
the Vector will work fine too.

I use Vector every time I can just to send the big giant heads into a tizzy.

 

I'm "mostly" in agreement. For curiosity's sake, though, I ran
a few simple timing tests and found that Vector took about 35% more
time than ArrayList (for the mix of operations I tried).

"That's HU-U-U-GE!" somebody's shouting, but does it truly make a
difference? What else is the program doing, and how much time does it
spend on things other than List manipulation? Like, say, constructing
the things that go into the Lists, ruminating about which Lists they
belong in, converting them to and from XML, ...?

FWIW, the same tests also found that the List formed by applying
Collections.synchronizedList() to an ArrayList was about 5% slower
than Vector ...

Also, there are a few API's in the core Java suite that still deal
in Vectors, particularly in Swing: DefaultComboBoxModel, JList, JTree,
DefaultTableModel, ...

 

This is not true. java.util.Vector.Itr<E> does go through the same
mutex as the Vector it is iterating. But, as Jörg and others have
noted, synchronizing all methods is not sufficient to ensure thread
safety - especially not if multiple method calls must be executed
atomically. Then you still need an explicit synchronized block.

Cheers

robert

 

And OSGI - or did they dump Java 1 support by now?

Cheers

robert

 

Well, even when the program is spending more time in other tasks, why
use a slow class when you can easily replace it with a faster one that
does the same thing?

And about the synchronization: in many cases, when you need
synchronization, you will need to synchronize something more than just
the Collection manipulation. And if the Collection handling is already
within a synchronized block, why use one more synchronization block
inside another one?

 

(Shrug.) A friend of mine once referred to such micro-optimizations
as cleaning the cigarette butts and bottle tops off the beach so the
sand would be nice and clean around the beached whales.

For new code I wouldn't use Vector (unless it's required by some
other API I can't control), but I wouldn't bother editing an old Vector-
using class simply to change it to ArrayList or something. I'd need to
perform a *lot* of operations on the List to recoup the editing time.
Perhaps you're a faster typist?

In a multi-threaded setting you need to pay close attention to
exactly which manipulations need to be atomic. Vector or the Lists
produced by Collections.synchronizedList() will guarantee atomicity
for the individual method calls, but (as has been pointed out a few
times already) the program may require some combinations of those to
be atomic. The classic example is iterating over the collection:
Just because .add() and .remove() and so on (and the Iterator methods
themselves) are atomic doesn't imply that the entire iteration is so.

One approach, as you suggest, is to wrap the entire iteration
in a synchronized block:

synchronized (theList) {
for (Thing t : theList) {
...
}
}

.... and, as you say, any synchronization provided by theList itself
is pure overhead here: You could just as well use an unsynchronized
List of some kind. But then you would have to ensure that every
*other* use of theList provided its own synchronization: You would
need to write

synchronized (theList) {
theList.add(theThing);
}

.... and lie awake nights wondering whether you (or that dopey intern)
had forgotten the dance somewhere, or had accidentally synchronized on
the wrong thing. I put it to you that you *would* use a synchronized
implementation for theList, even though the extra synchronization during
iteration would be overhead -- and with all that extra sleep, you'd be
in a better mood at breakfast.

Finally, I question the wisdom of a program design that requires
iterating over a collection shared by multiple threads. You'll need to
hold the collection's lock for the entire iteration, including whatever
goes on inside the iterating loop, and it's a Bad Idea to hold locks
for "macroscopic" time. I think this is what Josip Almasi was getting
at with "or go to java.util.concurrent" -- which usually involves more
than just dropping in a ConcurrentLinkedDeque or something, but requires
a fresh look at what the program really, truly needs to do.

Back to the original question: Vector is disparaged for two main
reasons: It's slower than ArrayList, and it's not fashionable. The
first reason is more often cited, but the latter probably has more
weight.

 

There is another effect of synchronization of all Vector methods which
has not yet been quoted as far as I can see: because of the Java memory
model every entry into and exit from a mutex forms a memory barrier
which requires some synchronization (sorry for the term here) between
thread local and global memory; it also permits some optimizations of
the JRE with regard to reordering operations. So even if each Vector
instance is used only inside at most one thread and the overhead of
synchronized in the usual simple tests where only a single instance is
manipulated in a real world application the synchronization between
local and global memory may actually have an adverse effect if many
threads are doing a lot of state changes. I would guess that the effect
is even worse on NUMA architectures but I do not have enough insight to
explore this further.

Kind regards

robert

 

it has built in thread safety which slows it down. With ArrayList it
is optional. I believe either way it is faster.