RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair

[Paul Sandoz]

On Oct 15, 2013, at 6:25 PM, Mike Duigou <mike.duigou at 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
>