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. 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 don't think that having a run-mode to enable CMEs to be thrown in this case would make things any better for the developer. What would prompt a developer to run in such a mode? In practice, I suspect it would merely act as a crutch with which folk would retrospectively beat the poor developer over the head, once corrupted EnumSets were detected, possibly (probably?) after their code is deployed. If there were agreement to throw CMEs by default, and have a run mode to disable them, I guess I'd be okay with that. I'm not sure that that would generally allay the backwards-compatibility concerns sufficiently for such a solution to be acceptable, however. Also, it didn't seem like that was the direction that the conversation was previously heading. As always, suggestions and guidance on how to progress the resolution to this problem forward gratefully accepted, 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
