Re: Collection implementations and fail-fast iterator problems.

From:

Patricia Shanahan <pats@acm.org>

Newsgroups:

comp.lang.java.programmer

Date:

Sat, 03 Nov 2007 09:31:42 -0700

Message-ID:

<fgi7pg$qd1$1@ihnp4.ucsd.edu>

Daniel Pitts wrote:

Roedy Green wrote:

On Fri, 02 Nov 2007 14:06:09 -0700, Daniel Pitts
<newsgroup.spamfilter@virtualinfinity.net> wrote, quoted or indirectly
quoted someone who said :

I'd like to avoid having to keep track of "to-be-deleted" and
"to-be-added" elements, but I don't see an elegant way to handle both
those cases without getting a ConcurrentModificationError.

see http://mindprod.com/jgloss/iterator.html#REMOVE

The problem is that the element to remove isn't necessarily the element
that the iterator is pointing to. For example.
class ItemHolder {
  Collection<Item> items;
  public void doAllSomething() {
   for (Item item: items) {
    item.doSomething();
   }
}

class Item {
  ItemHolder parent;
  public void doSomething() {
    for (Item item: parent.items) {
       item.affectBy(this);
       if (item.shouldBeRemovedNow()) {
          parent.items.remove(item);
       }
    }
    if (shouldAddNewItems()) {
       parent.items.add(createNewItem());
    }
  }
}

This is the gist of what happens. As you can see, there are multiple
iterators to deal with.

A few questions:

1. Is the underlying Collection large? (That affects whether it is
reasonable to make a working copy).

2. Does it have to work with arbitrary Collections?

3. How should added items be handled? Should they be processed in later
inner iterations of the same outer loop? Should they be processed in the
same run of the outer loop?

4. Similar questions for deleted items, but that is a simpler problem
because of the option of marking an item to indicate it is not really there.

Patricia