Joshua said:
Anything reflective is a dead giveaway, and I'm pretty sure that the two
classes have slightly different sizes, so you could observe differences
in memory characteristics.
In vector you can parametrisize the growing characteristics, either
by a constant increment or doubling the size. For this purpose there
is an extra field not found in ArrayList.
Array list always follows a 150% + 1 rule when growing the internal
data buffer. There is no extra field need to store some parameter.
But otherwise the two use the same data representation.
But I think it would not prevent me from using ArrayList instead
of Vector, that this parameter is missing. The 150% has its merits
over the strategies implemented in vector.
More seriously, the Collections API tweaked some method names
differently, so there are a few methods in Vector which are kept
around for legacy use (addElement, e.g.).
Yes when replacing Vector by ArrayList, one has to rename the method
calls. For example instead of addElement() one needs to use add(), and
instead of elementAt().
But renaming methods does not prevent me from using ArrayList. As
long each legacy method has a new buddy, I don't see any problem
whatever with it.
In general, an ArrayList is a list that happens to be backed by an
array. A Vector is a synchronized, automatically-growing array that
leaks details about its array all over the place; it was shoehorned
into the Collections API upon introduction to allow for a more
gradual, correct migration.
I don't see that Vector leaks more details than ArrayList about its
implementation. Could you make an example? I only see that the fields
of vector are protected, and well yes this means vector is not fully
encapsulated.
But I want to migrate to ArrayList whereever possible, so why should
I bother that Vector is not fully encapsulated. And if ArrayList has
the merrit that it is fully encapsulated the better.
But the protected fields would only be seen by a subclass, which could
sneak into some of your parameters of your methods, and spy on you or
cheat on you. Since vector is not final. That is a drawback. But same
problem with ArrayList.
Vector and ArrayList both implement the following protocolls:
AbstractList<E>
List<E>,
RandomAccess,
Cloneable,
Serializable
If only somebody would have had the brains to include setSize()
somewhere. List has the methods size(), add() and remove() in it.
setSize(n) could be neatly abstractly specified as having the
post condition size()=n and after.get(i)=before.get(i) for
i<before.size() and after.get(i)=null for i>=before.size() and
i<after.size().
And the AbstractList could implement abstractly the inefficient
setSize() that would use remove() and add(), when Random access is
present via index, or otherwise maybe with a backward iterator.
Backward iterator is also missing btw. And then concrete classes
could provide more efficient implementations if necessary.
Bye
Best Regards