where's your Vector, victor

Discussion in 'Java' started by bob smith, May 30, 2014.

  1. bob smith

    bob smith Guest

    I read that the Vector class is obsolete.

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

    Thank you.
     
    bob smith, May 30, 2014
    #1
    1. Advertising

  2. bob smith

    Josip Almasi Guest

    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...
     
    Josip Almasi, May 30, 2014
    #2
    1. Advertising

  3. bob smith

    Joerg Meier Guest

    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.
     
    Joerg Meier, May 30, 2014
    #3
  4. bob smith

    Eric Sosman Guest

    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
     
    Eric Sosman, May 30, 2014
    #4
  5. 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
     
    Knute Johnson, May 30, 2014
    #5
  6. bob smith

    Eric Sosman Guest

    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
     
    Eric Sosman, May 30, 2014
    #6
  7. 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
     
    Robert Klemme, May 30, 2014
    #7
  8. 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
     
    Robert Klemme, May 30, 2014
    #8
  9. 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
     
    Jukka Lahtinen, May 30, 2014
    #9
  10. bob smith

    Eric Sosman Guest

    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
     
    Eric Sosman, May 30, 2014
    #10
  11. 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
     
    Robert Klemme, May 31, 2014
    #11
  12. bob smith

    Roedy Green Guest

    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.
     
    Roedy Green, Jun 6, 2014
    #12
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. perseus
    Replies:
    20
    Views:
    799
    Mike Wahler
    Aug 13, 2003
  2. Joe Cipale

    OT - Victor.. please email me

    Joe Cipale, May 25, 2004, in forum: C++
    Replies:
    2
    Views:
    374
    Joe Cipale
    May 25, 2004
  3. Jack

    I Need A Vector, Victor

    Jack, Aug 19, 2005, in forum: C++
    Replies:
    1
    Views:
    311
    Alf P. Steinbach
    Aug 19, 2005
  4. Replies:
    12
    Views:
    630
    beryan
    Oct 16, 2005
  5. Replies:
    8
    Views:
    1,930
    Csaba
    Feb 18, 2006
Loading...

Share This Page