RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair
mike.duigou at oracle.com
Tue Oct 15 09:25:09 PDT 2013
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.
>>> 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.
I'd like to bring this set of changes to conclusion as soon as possible.
More information about the lambda-libs-spec-experts