Making java.util.Iterator.remove() for the iterators for EnumSet more resilient

[Mike Duigou]

Hi Neil;

I think your message presents the perfect "Speak now or forever hold your peace" opportunity. Barring any new substantive objections (I think you have addressed the previous objections more than adequately) I believe we should commit your patch to EnumSet and I will do so at the end of this week unless there are objections. I will do the required pre-integration testing this week so that everything should be ready to go by Friday (March 11th).

Mike

On Mar 3 2011, at 08:41 , Neil Richards wrote:

> On 3 March 2011 15:06, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> I think the main thing with this proposal is getting agreement that it is
>> the right thing to do. On one hand it avoids the set getting corrupted. On
>> the other hand it's masking a problem and really part of a bigger issue.
>> This isn't really my area but it kinda feels like we need a run mode or some
>> way to enable concurrent modification exceptions so that the developer has
>> some chance to fix the real issues.
>> 
>> -Alan.
> 
> 
> As I previously noted in the discussion [1], the current Javadoc API
> for EnumSet explicitly states that ConcurrentModificationException
> will never be thrown from its iterator. [2]
> 
> Also, Mike observed that other fixes which introduce the possibility
> of new ConcurrentModificationExceptions being thrown have previously
> been rejected on that basis. [3]
> 
> We may all agree that if one was to start from scratch, consistently
> throwing CMEs (at least, where it's feasible to detect them) would
> probably be the ideal approach.
> 
> But given the actual starting point, where existing API documentation
> explicits states that CMEs will *never* be thrown from EnumSet's
> iterator, and has done so since EnumSet's introduction in Java 5, I
> can appreciate there being nervousness about changing that explicit
> (EnumSet-iterator-specific) contract with the user/developer at this
> point.
> 
> Given this nervousness, my suggested change implements the next best
> strategy, which is to make the iterator implementation tolerate the
> modification without corrupting the underlying EnumSet.

I agree that this is the best possible change.

> This was, presumably, the behaviour as intended by the original author
> of the EnumSet API Javadoc.
> (In hindsight, one might disagree with the design choice made, but not
> that the design choice *was* made, given its explicit documentation).
> 
> To leave the EnumSet iterator's code in its current (unchanged) form,
> I would argue, would be the worst possible outcome: It neither
> protects the contents of EnumSets from being "gratuitously" corrupted
> due to modification from both the iterator and the set (by being
> tolerant of this possibility), nor does it alert the developer to the
> error they are making.
> (I describe the corruption as "gratuitous" because it is so trivial to
> avoid for this iterator).

I agree.

> As always, suggestions and guidance on how to progress the resolution
> to this problem forward gratefully accepted,

This is exactly the right way to proceed. Thanks!

> Thanks,
> Neil
> 
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-January/005763.html
> [2] http://download.oracle.com/javase/1.5.0/docs/api/java/util/EnumSet.html
> [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-February/005799.html
> 
> --
> Unless stated above:
> IBM email: neil_richards at uk.ibm.com
> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU