Name: ssT124754 Date: 03/01/2001



size() of synchronized collection is not synchronized.
synchronization is not only for mutual exclusion, it also the only guaranty
that changes to fields are visible to other threads.
If say one thread changes the size of a say a vector,
another thread that checks that vector's size wouldn't necessarily see that
change because with no synchronization protection, the thread can copy the size
value to it's local memory and won't update it until it encounters a memmory
barrier.
A two sec work around would be "sure, so synchronized on the Vector", but:
1. how many really do it / aware of this issue? if the spec says that a
collection class is synchronized that it should be fully synchronized. period.
this is *really* no small change.

Even Sun enginners are not that aware of it.
take javax.swing.table.DefaultTableModel for example:

    public int getRowCount() {
        return dataVector.size();
    }

changes to the Vector size would not be necessarily be visible to the thread
doing the repaint. if the vector size is decremented, it can result in an
ArrayIndexOutOfBoundsException.

The author of that code probably assumed that size() returns the *actual* value
while in a multithreaded environment, especially in dual-cpu (but even with a
single one) it is more than likely that size() would return stale values.


Please fix it, or make it BOLDLY clear that size is not synchronized and that
in multithreaded environment it returns stale values.
This is a subtle point of the Java memory model, most programmers aren't aware
of it, especially Swing folks, that account for numerous bug reports and bug
votes.
(Review ID: 117938)
======================================================================