ConcurrentModificationException not thrown when removing the next to last element , less than expected number of iterations

FULL PRODUCT VERSION :
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
The method
java.util.AbstractList.Itr.hasNext()
does not check for modification.

That leads in one missing iteration loop when removing the next to last element.

Assumtion is that when "for each" over an list with 3 elements the loop is performed exactly 3 times or a ConcurrentModificationException is thrown.

When performing the next code the loop is iterated 2 times only and no exception is coming up:

@Test
public void testRemove2ndOf3() {
List<String> tempArrayList = new ArrayList<String>();
tempArrayList.add("1");
tempArrayList.add("2");
tempArrayList.add("3");

List<String> tempIterated = new ArrayList<String>();
for (String tempString : tempArrayList) {
tempIterated.add(tempString);
if (tempString.equals("2")) {
tempArrayList.remove(tempString);
// 3 is still in the list
}
}
assertEquals("Expected to iterate 3 times, but found only " + tempIterated, 3, tempIterated.size());
// Normally fail("Expected ConcurrentModificationException");
}


Currently loop is performed without exception but the checking List tempIterated contains [1,2] only.


When removing the "1" element instead of "2" the above code throws an ConcurrentModificationException as expected.

ADDITIONAL REGRESSION INFORMATION:
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Perform the test testRemove2ndOf3 specified in the Description.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
ConcurrentModificationException
ACTUAL -
Loop is iterated 2 times and terminates normallly (even there were 3 elements in)

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Do not remove in an foreach loop at all (is best practice anyway)