Even if the best collections depends on the type of operations you need
to perform, as a rule of thumb you can use :
array - for operating on fixed number of elements (you know how many
element tou will use and the number will not change in time).
java.util.List - are the best choice in case of modifiable collections
(adding, removing etc).

We need to say that java.util.Vector is only a possibile implementation
of java.util.List.

If you need synchronization (i.e. you collection is shared among
multiple threads) than you need to use java.util.Vector (and take any
other concern involved in synchronization).

If you don't need synchronization  than java.util.ArrayList ot
java.util.LinkedList may be a better choice. In particular the first is
better when tou mostly access and add elements to the end of the list,
while the second is better while removing and adding elements at random
point.

    I think you're still overlooking the fact that a Vector and
an array are different things.  For example, you cannot insert
a float into a Vector.  A bit of magic called "autoboxing" takes
your primitive float value, creates a Float object from it, and
it's the Float that actually gets inserted.  It's not all *that*
expensive to create objects -- the people who write the JVM have
a strong incentive to keep the cost down -- but the amount of work
is certainly more than that involved in plunking a float value
into a float[] array.  There's also the memory issue (c.f. another
recent thread you've been involved in): The float will occupy four
bytes of memory, period, while the Float will use additional memory
to represent its "objectness" in addition to the naked value.

    That's not to say that float[] is necessarily the right answer.
Once you have created an array its size is forever fixed: you
cannot add and delete elements.  (You can change the values stored
in existing elements, but that's a different matter.)  If you make
a float[N] array and later discover that you need N+M values, your
only recourse is to create a new array and copy what's needed from
the old one.  Vector takes care of this automatically.  Even if it
does so by copying arrays behind the scenes and thus expends as much
work as if you had managed arrays manually, the convenience is not
to be sneezed at.  Expenditure of computer time is not the only
criterion of worth; one should also think about the expenditure of
programmer time.  (Which is a better use of your talents: writing
code to slosh arrays around, or thinking up creative ways to do the
analysis your problem requires?)

    Finally, micro-benchmarks can be very tricky.  Even in compiled
languages it has become harder and harder to write good ones: the
compilers' optimizers have grown more and more aggressive, and are
more apt to recognize and discard whole swathes of "useless" code.
`for (x=0; x<1000000; ++x) /* empty */ ;' may become `x = 1000000;'.
In semi-compiled, semi-interpreted, semi-JITted, garbage-collected
Java it is even more difficult to write a meaningful micro-benchmark.
Your result of "2x computational speed" is plausible, certainly, but
such measurements need to be viewed with a great deal of caution.