where's your Vector, victor


B

bob smith

I read that the Vector class is obsolete.

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

Thank you.
 
Ad

Advertisements

J

Josip Almasi

I read that the Vector class is obsolete.

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

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

Joerg Meier

I read that the Vector class is obsolete.
Can someone tell me in a nutshell why this is so?

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
 
E

Eric Sosman

Same as with Hashtable.
It's all synchronized, = slow.
And to make things worse, returned iterators are not synchronized:)

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

Knute Johnson

I read that the Vector class is obsolete.

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

Thank you.

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

Eric Sosman

Mostly mythology. The Vector provides some additional functionality
over a synchronized List but it's probably not something you will need.

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

:)

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

Advertisements

R

Robert Klemme

Same as with Hashtable.
It's all synchronized, = slow.
And to make things worse, returned iterators are not synchronized:)

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
 
R

Robert Klemme

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

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

Cheers

robert
 
J

Jukka Lahtinen

Eric Sosman said:
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

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?
 
E

Eric Sosman

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?

(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? ;)
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?

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

Robert Klemme

On 5/30/2014 5:30 PM, Jukka Lahtinen wrote:

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.
Finally, I question the wisdom of a program design that requires
iterating over a collection shared by multiple threads.

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
 
Ad

Advertisements

R

Roedy Green

I read that the Vector class is obsolete.

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

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

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top