On Oct 15, 2013, at 6:25 PM, Mike Duigou <mike.dui...@oracle.com> wrote:
> > On Oct 14 2013, at 02:32 , Paul Sandoz wrote: > >>> Virtually all the cases where CME is thrown in the "new" Map defaults are >>> the points where previously the implementation would have looped/retried. >>> >> >>>> For the cases where no function values are passed it has very limited >>>> value, we know it is effectively useless for non-current collections being >>>> modified concurrently. >>> >>> Understood. The alternative would be to GIGO these situations, return and >>> ignore them. >>> >> >> Yeah, unnecessarily complicates the code. > > It does detect legitimate errors and it makes me uncomfortable to just ignore > them. > It is not deterministic. Does HashMap's implementation of putIfAbsent throw a CME? >>>> For the cases where a function value is passed and it modifies the map >>>> then it could have some value. But i wonder, for any non-looping function >>>> value accepting method on Map (anything other than forEach/replaceAll), >>>> whether it is just simpler to state: "if a function value modifies the >>>> entry under computation then this method may return incorrect results`". >>> >>> Modification of any other entry may have the same result. >> >> Yes, although IIUC modification, by the function value, of other entries >> will not interfere with that of operating on the entry under computation. A >> more general recommendation is the function values should be stateless. >> >> >>> I suspect that modification by some other thread is as likely to be a >>> problem as modification by the function. >>> >> >> And under concurrent modification we cannot deterministically detect. CME in >> the non-concurrent collections is only useful for detecting serial >> modification due to inversion of control, and in these particular cases it >> is really very limited as to what it detects. > > True, but it generally doesn't impose any extra cost. The error detection > happens as a side effect of necessary operations. > There cost to code complexity. I would argue that additional complexity is not worth it given the limits of what can be detected. I guess you know my opinion: remove 'em. So i will be silent for a bit and see if anyone else speaks up :-) Paul. > I'd like to bring this set of changes to conclusion as soon as possible. > > Mike >
