Why doesn't this code throw a ConcurrentModificationException?

Question

Why doesn't this code throw a ConcurrentModificationException? It modifies a Collection while iterating through it, without using the Iterator.remove() method, which is meant to be the only safe way of removing.

List<String> strings = new ArrayList<>(Arrays.asList("A", "B", "C")); for (String string : strings)     if ("B".equals(string))         strings.remove("B"); System.out.println(strings); 

I get the same result if I replace the ArrayList with a LinkedList. However if I change the list to ("A", "B", "C", "D) or just ("A", "B") I get the exception as expected. What is going on? I am using jdk1.8.0_25 if that is relevant.

EDIT

I've found the following link

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4902078

The relevant section is

The naive solution is to add comodification checks to hasNext in AbstractList, but this doubles the cost of comodification checking. It turns out that it is sufficient to do the test only on the last iteration, which adds virtually nothing to the cost. In other words, the current implementation of hasNext:

    public boolean hasNext() {         return nextIndex() < size;     } 

Is replaced by this implementation:

    public boolean hasNext() {         if (cursor != size())             return true;         checkForComodification();         return false;     } 

This change will not be made because a Sun-internal regulatory body rejected it. The formal ruling indicated that the change "has demonstrated the potential to have significant compatibility impact upon existing code." (The "compatibility impact" is that the fix has the potential to replace silent misbehavior with a ConcurrentModificationException.)

Answer 1

As a general rule, ConcurrentModificationExceptions are thrown when the modification is detected, not caused. If you never access the iterator after the modification, it won't throw an exception. This minute detail makes ConcurrentModificationExceptions rather unreliable for detecting misuse of data structures, unfortunately, as they only are thrown after the damage has been done.

This scenario doesn't throw a ConcurrentModificationException because next() doesn't get called on the created iterator after the modification.

For-each loops are really iterators, so your code actually looks like this:

List<String> strings = new ArrayList<>(Arrays.asList("A", "B", "C")); Iterator<String> iter = strings.iterator(); while(iter.hasNext()){     String string = iter.next();     if ("B".equals(string))         strings.remove("B"); } System.out.println(strings); 

Consider your code running on the list you provided. The iterations look like:

1. hasNext() returns true, enter loop, -> iter moves to index 0, string = "A", not removed
2. hasNext() returns true, continue loop -> iter moves to index 1, string = "B", removed. strings now has length 2.
3. hasNext() returns false (iter is currently at the last index, no more indices to go), exit loop.

Thus, as ConcurrentModificationExceptions are thrown when a call to next() detects a that a modification has been made, this scenario narrowly avoids such an exception.

For your other two results, we do get exceptions. For "A", "B", "C", "D", after removing "B" we are still in the loop, and next() detects the ConcurrentModificationException, whereas for "A", "B" I'd imagine it's some kind of ArrayIndexOutOfBounds that's being caught and re-thrown as a ConcurrentModificationException