Generics

[Andreas Leitgeb]

What's wrong with multiple re-allocations? AIUI, ArrayList grows its capacity
by doubling the array size,

I didn't intend to cause so much fuss with those few methods that Vector
and ArrayList have, but plain List hasn't. I dislike fuss, which is
the reason, that when I need something synchronized then I'd rather
use a Vector than any of those Collections that I need to cast spells
on to make synchronized, and then even lose some of the functionality.
If my needs were more complicated, and I'd need extra sync-fuss even
above what the Vector offers, then I can just as well use any other
Collection and do all the sync myself.

 

[Lew]

I fail to see in which way a Vector was any *less* "thread safe" than
a Collections.synchronizedList(new ArrayList(...)).

It isn't.

Docu for synchronizedList says:
" Returns a synchronized (thread-safe) ..."
Note, it doesn't say "synchronized and also thread-safe",
but rather seems to consider those two to be like synonyms.

Yes, and that is one instance of Sun's documentation leading people astray.

Individual methods are synchronized; using two synchronized methods separately
is not inherently thread-safe; consider check-and-set operations.

The OP's problem seemed to call for a check-and-set (check capacity, and
increase if needed, then add()). Even with Vector or synchronizedList(), this
opens the barn door for a race condition without explicit synchronization. As
I said, in this case I wouldn't use Vector or synchronizedList(); I'd declare
the variable a plain ArrayList for the extra methods the OP wanted (or just
List, since I think they're not really needed), and dispense with implicit
synchronization altogether.

Docu for Vector only says:
" Vector is synchronized.

What operations can I do on a synchronizedList without extra
synchronization-block, that I cannot do on a Vector likewise
and with same level of real thread-safety?

None.

ArrayList and synchronizedList() give you Lists without the non-collections
methods of Vector and without Enumeration. I like synchronizedList() better
than Vector because it lacks unneeded machinery; it Occam's Razors itself into
my heart.

It's not what List has that Vector doesn't; it's what Vector has that List
doesn't that makes me excoriate Vector.

 

[Andreas Leitgeb]

It isn't.

Ok, so at least I didn't miss anything on factual side

Individual methods are synchronized; using two synchronized methods separately
is not inherently thread-safe; consider check-and-set operations.

Now I'm a bit surprised about your definition of "thread-safety",
because in a thread not very long ago, you insisted on static
methods being principially thread-safe, without consideration
of context...

PS: Occam's Razor says "don't buy more than you need" with a
rather philosophical meaning of buying . Anyway, I don't
need to buy Vector's extra features. I get them for free.
Even quite the opposite: synchronizedList costs me more
characters to type.

 

[Lew]

PS: Occam's Razor says "don't buy more than you need" with a
rather philosophical meaning of buying . Anyway, I don't
need to buy Vector's extra features. I get them for free.
Even quite the opposite: synchronizedList costs me more
characters to type.

Typing effort is not part of my metric. The presence of unneeded machinery is
the consideration. It isn't ever needed, so why include it when ArrayList is
out there with exactly what's needed?

Now I'm a bit surprised about your definition of "thread-safety",
because in a thread not very long ago, you insisted on static
methods being principially thread-safe, without consideration
of context...

I insisted that they /could/ be thread-safe, not without consideration of
context. Don't misrepresent my points.

 

[Mark Space]

PS
PPS

P. S. = post scriptum, after the writing.

P. P. S. = post post scriptum, after the after writing.

P. P. P. S = post post post scriptum, after the after-after writing.

etc.