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

  2. bob smith

    Josip Almasi Guest

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

  3. bob smith

    Joerg Meier Guest

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

    Eric Sosman Guest

    One or the other of these arguments might be relevant, but
    they can't both be relevant at the same time.
     
    Eric Sosman, May 30, 2014
    #4
  5. 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, May 30, 2014
    #5
  6. bob smith

    Eric Sosman Guest

    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, ...
     
    Eric Sosman, May 30, 2014
    #6
  7. 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. And OSGI - or did they dump Java 1 support by now?

    Cheers

    robert
     
    Robert Klemme, May 30, 2014
    #8
  9. 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, May 30, 2014
    #9
  10. bob smith

    Eric Sosman Guest

    (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.
     
    Eric Sosman, May 30, 2014
    #10
  11. 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

    it has built in thread safety which slows it down. With ArrayList it
    is optional. I believe either way it is faster.
     
    Roedy Green, Jun 6, 2014
    #12
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.