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 <[email protected]> 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
