Understanding fail-fast behaviour of Vectors

[sumit anand kumar]

In Java docs its mentioned :

The Iterators returned by Vector's iterator and listIterator methods are fail-fast: if the Vector is structurally modified at any time after the Iterator is created, in any way except through the Iterator's own remove or add methods, the Iterator will throw a ConcurrentModificationException. Thus, in the face of concurrent modification, the Iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined time in the future. The Enumerations returned by Vector's elements method are not fail-fast.

Why is Iterators failfast and why not enumerations

import java.util.Enumeration;
import java.util.Vector;


public class CheckThreadSafetyEnumeration {
	
	public static void main(String[] args) {
		Vector<String> v = new Vector<String>();
		v.add("first");
		v.add("second");
		v.add("third");
		Enumeration<String> e = v.elements();
		if(e.hasMoreElements()) {
			System.out.println(e.nextElement());
		}
		v.add(1, "fourth_at_second");
		while(e.hasMoreElements()) {
			System.out.println(e.nextElement());
		}
	}

}

Output :

first
fourth_at_second
second
third


Also in the vector code, theres a variable modCount that gets incremented once in all operations done on vectors. Whats its use?

[Jeff Verdegan]

sumit anand kumar wrote:
Why is Iterators failfast and why not enumerations

Because Enumerations are older. Vector and Hashtable and Enumeration pre-date the Collections framework, which was added in v1.2. It was more thoroughly thought-out and better designed than the previous classes.

Also in the vector code, theres a variable modCount that gets incremented once in all operations done on vectors. Whats its use?

Presumably the Iterator uses it to know if somebody else has modified the Vector, and, hence, if it needs to throw CME.

[Campbell Ritchie]

Not certain, but I think there is an integer value somewhere in a List, which is incremented every time a method like add() remove() etc is called. A copy of that count is held in the Iterator, and whenever an Iterator method is invoked, it compares its copy of the count with the original field in the List., then it can call something like . . .

if (this.count != that.count)
{
   throw new ConcurrentModificationException();
}

[edit]I see Jeff V has already mentioned the count variable. Sorry for repeating this[/edit]

[Martin Vashko]

I'm probably stating the obvious, but let me emphasize you should not rely on this behavior, that is, not use it to control your program flow. It is a measure targeted at helping to identify bugs early. Also, the fail-fast mechanism isn't guaranteed to throw a CME in all cases of concurrent modifications, only in most of them.

[Campbell Ritchie]

There was a thread somewhere about how to circumvent that fail-fast behaviour. I shan’t try to find it!

[sumit anand kumar]

Any luck ?

Campbell Ritchie wrote:There was a thread somewhere about how to circumvent that fail-fast behaviour. I shan’t try to find it!

[Jeff Verdegan]

sumit anand kumar wrote:Any luck ?

Campbell Ritchie wrote:There was a thread somewhere about how to circumvent that fail-fast behaviour. I shan’t try to find it!

Since he said that he will NOT try to find it, I expect he was completely successful in not finding it.

[Campbell Ritchie]

Yes, I was successful in not looking for it. I was very busy at the time, so I didn’t have time to look.