commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Morgan Delagrange" <>
Subject Re: [Collections] Bug or Feature? - SequencedHashMap iterators do not throw ConcurrentModificationExceptions
Date Wed, 08 May 2002 19:13:14 GMT

----- Original Message -----
From: "Michael A. Smith" <>
To: "Jakarta Commons Developers List" <>;
"Morgan Delagrange" <>
Sent: Wednesday, May 08, 2002 1:45 PM
Subject: Re: [Collections] Bug or Feature? - SequencedHashMap iterators do
not throw ConcurrentModificationExceptions

> On Wed, 8 May 2002, Morgan Delagrange wrote:
> > In tracking down a bug in LRUMap, I added a new unit test to testMap()
> > check if all our Map Iterators throw ConcurrentModificationExceptions
> > the underlying collection is modified.  SequencedHashMap does not.  I
> > that it's not absolutely _required_ to handle modifications that way,
> > should we classify this as a bug or an unsupported feature?  It seems
> > not to throw a ConcurrentModificationException, because it probably
> > the behaviour of the Iterator indeterminate, and in the case of LRUMap I
> > think it's leading to an infinite promotion loop.
> Not throwing a ConcurrentModificationException is not a violation of the
> contracts, so it isn't really a "bug".  I'm a bit concerned though because
> I believe the SequencedHashMap should support concurrent modifications via
> the map or the iterator.
> Iterators should be able to continue iterating and see any concurrent
> modifications made to the map*.  If the iterator is looking at an element
> that is removed, and then "next" is called, the iterator should continue
> where it left off, even though the element was removed.  If an element is
> added, it's added at the end of the list, and the iterator should iterate
> to it when it gets to the end of the list (note: if the iterator has
> already reached the end of the list, hasNext is false, and then a new
> mapping is added, the iterator will then return true from hasNext as the
> new element can then be iterated over).

I think it may be working all too well.  The LRUMap promotion removes keys
and re-adds them to the end, which I think the iterator may be reading over
and over.  Perhaps a ConcurrentModificationException would be safer.

> That is, of course, assuming things are working properly.  If you're
> seeing problems, then maybe something *is* broken, and thus a bug may be
> lurking.  I'll take a look tonight as to why LRUMap is getting in an
> infinite loop just in case there really is a bug somewhere.

Just to give you a bit of background...  It turns out that, somehow, I
forgot to add get(Object) promotion to LRUMap and that, somehow, we didn't
have any unit tests for it.  So I'm trying to add that promotion, but I'm
getting this infinite loop for the testSequenceMap test in the
TestSequencedHashMap class.  It's clearly caused by the new get(Object)
promotion somehow.  Feel free to take a look; I'm done for today.  Getting

> As for throwing ConcurrentModificationException, I really don't think its
> necessary.  There's no reason why we can't support modification of the map
> while an iterator exists with this particular collection.
> regards,
> michael
> * This does not mean that SequencedHashMap is thread-safe.  It just means
> that if only one thread at a time is operating on the map or its
> iterators, then things should work without any problems.
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message