On Tue, 9 Apr 2002, Jack, Paul wrote: > List and Map objects can return views on their contents > that can be modified. For instance, elements can be > removed from an ArrayList via its iterator(). Elements > can be removed from a map via its keySet() or its values() > collection. A TreeMap can also return a submap that can > be modified. Generally, changes on a view of a collection > are reflected in the original and vice-versa. > > The problem is, with FastArrayList or FastHashMap, in "fast" > mode, if somebody tries to modify a collection view (say, a > keySet() of a FastHashMap) they will never enter the FastHashMap's > monitor. The state of the FastHashMap can become corrupted if > more than one thread attempts to modify its keySet(); and threads > attempting a fast get(Object) on a FastHashMap while another > thread modifies its keySet() may get faulty data back.
Can you file this as a bug? That way we can be sure to track it. http://nagoya.apache.org/bugzilla/ > I'd recommend using the "unmodifiable" methods of the > java.util.Collections class to make the collection views immutable. > This would solve the problem, but technically violate the contract > of java.util.Map and java.util.List (which specify that views on > a map or list must support all operations the original map or list > supported). Unfortunately, making it unmodifiable is a non-baskwards compatible change. There may be users out there that are relying on the returned views being modifiable. It shouldn't be too difficult to synchronize properly in the returned views -- just requires some time to actually work on it. regards, michael -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
