Analysis of Mauve failures - Part 2

[Mark Wielaard]

Hi,

On Thu, 2002-04-04 at 05:34, Bryce McKinlay wrote:
> Mark Wielaard wrote:
> >>FAIL: gnu.testlet.java.util.ArrayList.AcuniaArrayListTest: should throw a ConcurrentModificationException -- 7 (number 1)
> >>
> >set(int, Object) does not make the Iterator throw a
> >ConcurrentModificationException. Seems to not be required by the spec
> >though.
> 
> set() should not update modCount (and thus not cause iterators to throw 
> ConcurrentModificationException), because it is not a structural change 
> to the list. Only operations that could result in adding or removing 
> entries should update modCount. So, the test is wrong.

Where does the definition of structural change come from? Although I
understand what you say I cannot find this definition in the spec. The
spec says that all standard Collection classes have to be fail-fast and
it says that the behavior of an iterator is unspecified if the
underlying collection is modified while the iteration is in progress in
any way other than by calling this method (Iterator.remove()).

So we are interpreting "modification of an collection" as modification
of the actual "structure" of the collection. That seems like a good
definition, but I cannot find it in the spec/api.

I quickly checked against kaffe and a Sun JDK and they seem to agree
since the following program does not throw a
ConcurrentModificationException:

import java.util.*;
public class FailFast
{
  public static void main(String[] args)
  {
    ArrayList al = new ArrayList();
    Object o = new Object();
    al.add(o);
    al.add(new Object());
    Iterator it = al.iterator();
    while (it.hasNext())
      {
        // al.add(new Object());
        // al.remove(o);
        // al.remove(new Object());
        al.set(0, new Object());
        it.next();
      }
  }
}

But uncommenting the al.add() or the al.remove(o) does throw, but the
al.remove(new Object()) does not throw.

Cheers,

Mark