Question

I’m having problems with Iterator.remove() called on a HashSet.

I’ve a Set of time stamped objects. Before adding a new item to the Set, I loop through the set, identify an old version of that data object and remove it (before adding the new object). the timestamp is included in hashCode and equals(), but not equalsData().

for (Iterator<DataResult> i = allResults.iterator(); i.hasNext();) {     DataResult oldData = i.next();     if (data.equalsData(oldData))     {            i.remove();         break;     } } allResults.add(data) 

The odd thing is that i.remove() silently fails (no exception) for some of the items in the set. I’ve verified

• The line i.remove() is actually called. I can call it from the debugger directly at the breakpoint in Eclipse and it still fails to change the state of Set

• DataResult is an immutable object so it can’t have changed after being added to the set originally.

• The equals and hashCode() methods use @Override to ensure they are the correct methods. Unit tests verify these work.

• This also fails if I just use a for statement and Set.remove instead. (e.g. loop through the items, find the item in the list, then call Set.remove(oldData) after the loop).

• I’ve tested in JDK 5 and JDK 6.

I thought I must be missing something basic, but after spending some significant time on this my colleague and I are stumped. Any suggestions for things to check?

EDIT:

There have been questions – is DataResult truly immutable. Yes. There are no setters. And when the Date object is retrieved (which is a mutable object), it is done by creating a copy.

public Date getEntryTime() {     return DateUtil.copyDate(entryTime); }  public static Date copyDate(Date date) {     return (date == null) ? null : new Date(date.getTime()); } 

FURTHER EDIT (some time later): For the record — DataResult was not immutable! It referenced an object which had a hashcode which changed when persisted to the database (bad practice, I know). It turned out that if a DataResult was created with a transient subobject, and the subobject was persisted, the DataResult hashcode was changed.

Very subtle — I looked at this many times and didn’t notice the lack of immutability.

Answer 1

I was very curious about this one still, and wrote the following test:

import java.util.HashSet; import java.util.Iterator; import java.util.Random; import java.util.Set;  public class HashCodeTest {     private int hashCode = 0;      @Override public int hashCode() {         return hashCode ++;     }      public static void main(String[] args) {         Set<HashCodeTest> set = new HashSet<HashCodeTest>();          set.add(new HashCodeTest());         System.out.println(set.size());         for (Iterator<HashCodeTest> iter = set.iterator();                 iter.hasNext();) {             iter.next();             iter.remove();         }         System.out.println(set.size());     } } 

which results in:

1 1 

If the hashCode() value of an object has changed since it was added to the HashSet, it seems to render the object unremovable.

I’m not sure if that’s the problem you’re running into, but it’s something to look into if you decide to re-visit this.