[Bug classpath/24632] New: java.util.HashMap$HashIterator.hasNext throws ConcurrentModificationException

[gnuclasspath dot 10 dot bertnase at spamgourmet dot com]

Despite the javadoc and general contract of java.util.Iterator.hasNext() the
HashMap iterarator inner class throws a ConcurrentModificationException when
the HashMap has been modified before the call to hasNext(). 
As this has not been declared in any way in the interface java.util.Iterator
and even in case it would have been said, would be a behaviour incompatible
with the Sun JDK class library, I think the exception should not be thrown in
hasNext. 
Though the current behaviour seems to be logical and ensures consistent
behaviour of the iterator, it is inconsistent wit the Sun JDK behaviour and
thus breaks existing code which will work fine using Suns classlib.

This is the case with Apache Axis 1.3, where this code fragment exists in
org.apache.axis.client.Call:2561:

Iterator it = outParams.keySet().iterator();
while (it.hasNext() && findReturnParam) {
    QName qname = (QName) it.next();
    ParameterDesc paramDesc =
        operation.getOutputParamByQName(qname);
    if (paramDesc == null) {
        // Doesn't match a paramter, so use this for the return
        findReturnParam = false;
        result = outParams.remove(qname);
    }
}

This code runs fine on Sun classlib, but breaks when using Gnu classpath as the
while- statement calls hasNext() before being cancelled because of the second
expression being false.

This particular issue could be fixed easily in the Axis code(by swapping the
expressions in the while-condition), but considering the huge amount of Java
libraries in the world, which may rely on the behaviour of Iterator.hasNext()
to not throw an Exception, I think that changing the Gnu classpath
implementation to behave compatible to Sun's implementation (and additionally
obeying the contract defined by the java.util.Iterator interface) would be the
best solution to maintain compatibility.

I am not sure whether other Iterator implementations in the Gnu Classpath class
library expose the same odd behaviour, so this sould be checked too when
considering to fix this issue(by deleting lines 856 and 857 from
java/util/HashMap.java).

As for the version of Gnu classpath in which I found the bug, I cannot really
tell, (the source file HashMap.java does not have a CVS $Id$ or something...),
but in case this may help: It is the version included in the kaffe-1.1.6
release.


-- 
           Summary: java.util.HashMap$HashIterator.hasNext throws
                    ConcurrentModificationException
           Product: classpath
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: classpath
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: gnuclasspath dot 10 dot bertnase at spamgourmet dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24632