FULL PRODUCT VERSION :
java version "1.5.0_08"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03)
Java HotSpot(TM) Server VM (build 1.5.0_08-b03, mixed mode)

java version "1.6.0-beta2"
Java(TM) SE Runtime Environment (build 1.6.0-beta2-b81)
Java HotSpot(TM) Server VM (build 1.6.0-beta2-b81, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Linux aleph 2.6.17 #2 SMP PREEMPT Wed Aug 30 21:35:08 CEST 2006 i686 GNU/Linux

EXTRA RELEVANT SYSTEM CONFIGURATION :
This is purely a Java issue. No native code or hw involved.

A DESCRIPTION OF THE PROBLEM :
Collections.reverse() uses two ListIterator instances concurrently on the same list. This fails under three conditions:
1. if the list iterators are fast-fail for List.set() modifications and
2. if the list does not implement RandomAccess and
3. if the list contains more than 18 elements.

This failure isn't clear from the documentation of either ListIterator, List, AbstractList, or Collections. The closest is the documentation of modCount in AbstractList (there is no requirement to actually subclass AbstractList though). It states that subclasses should increment modCount in add() and remove() methods. Subclasses that conform cannot provide fast-fail iterators for concurrent set() calls. However, the ListIterator of AbstractList can actually cope with modifications to modCount in set(), because it reads out the new value of modCount after the set() call.


There are multiple ways in which this could be fixed, some involving changing the comments for modCount, Collections.reverse() or ListIterator.set(), however, probably the best way to fix it is to change Collections.reverse() not to use two iterators simultaneously. Neither List nor ListIterator document fail-fast behavior and it is merely coincidence that Collections.reverse() actually works with all (most) existing implementations of the List/ListIterator interface.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and execute the included source code.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I expected the lists content to be reversed.
ACTUAL -
An Exception.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:374)
at java.util.AbstractList$ListItr.set(AbstractList.java:411)
at java.util.Collections.reverse(Collections.java:377)
at test.ArrayListBug.main(ArrayListBug.java:48)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package test;

import java.util.AbstractList;
import java.util.Collections;

public class ArrayListBug extends AbstractList<Object> // implementing RandomAccess would avoid the problem
{

private Object[] data = new Object[0];

public ArrayListBug()
{/*OK*/}

@Override
public void add(int index, Object o)
{
Object[] temp = new Object[data.length+1];
System.arraycopy(data, 0, temp, 0, index);
temp[index] = o;
System.arraycopy(data, index, temp, index+1, data.length-index);
data = temp;
modCount++;
}

@Override
public Object set(int index, Object o)
{
Object result = data[index];
data[index] = o;
modCount++; // allowed by specification but not considered by Collections.reverse()
return result;
}

@Override
public Object get(int index)
{ return data[index]; }

@Override
public int size()
{ return data.length; }


public static void main(String[] args)
{
ArrayListBug list = new ArrayListBug();
for (int i = 0; i < 18; i++)
list.add(new Object());
Collections.reverse(list);
}

}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
there are four possible workarounds:

 - do not modify modCount in set()
   This avoids the detection of the concurrent modification, but will also avoid detection of actual concurrent modifications.

 - implement RandomAccess
   This avoids the bad code in Collections.reverse(), but is a bad idea for list implementations that do not actually support random access.

 - never have more than 18 elements in a list
   This avoids the bad code in Collections.reverse(); this is clearly unfeasible in general.

 - use custom reverse method
   This avoids the bad code in Collections.reverse(); this is clearly unfeasible when an Object of the class is handed to 3rd party code (or if someone accidently calls Collections.reverse with the list.