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.

 

On 05/30/2014 10:11 AM, bob smith wrote:
> 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...

 

On Fri, 30 May 2014 01:11:48 -0700 (PDT), bob smith wrote:

> 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

--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

 

On 5/30/2014 6:45 AM, Josip Almasi wrote:
> On 05/30/2014 10:11 AM, bob smith wrote:
>> 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

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

--
Eric Sosman
d

 

On 5/30/2014 01:11, bob smith wrote:
> 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.

--

Knute Johnson

 

On 5/30/2014 10:32 AM, Knute Johnson wrote:
> On 5/30/2014 01:11, bob smith wrote:
>> 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.

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

--
Eric Sosman
d

 

On 30.05.2014 12:45, Josip Almasi wrote:
> On 05/30/2014 10:11 AM, bob smith wrote:
>> 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

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

 

On 30.05.2014 17:31, Eric Sosman wrote:

> 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

 

Eric Sosman <> writes:

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

--
Jukka Lahtinen

 

On 5/30/2014 5:30 PM, Jukka Lahtinen wrote:
> Eric Sosman <> writes:
>
>> 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?

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

--
Eric Sosman
d

 

On 31.05.2014 00:23, Eric Sosman wrote:
> On 5/30/2014 5:30 PM, Jukka Lahtinen wrote:

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

> 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

 

On Fri, 30 May 2014 01:11:48 -0700 (PDT), bob smith
<63.net> wrote, quoted or indirectly quoted someone
who said :

>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.
--
Roedy Green Canadian Mind Products http://mindprod.com
In former times, people who craved absolute power became gangsters.
Today, they become computer programmers.