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

[Paul Sandoz]

On Oct 16, 2013, at 1:52 PM, David Holmes <david.holmes at oracle.com> wrote:
>>> Perhaps HashMap's implementations should throw CME?
>>> 
>> 
>> Perhaps, seems to be going beyond the call of duty. My inclination is not to bother. It becomes most relevant with forEach since the consumer will have side-effects that might make it easier to unintentionally slip in a modification to the map itself.
> 
> I think there is a lot to be said for consistency.

Yes, i was proposing to consistently not support it for non-traversal methods :-)


> At present it seems we don't have a clear idea on how these methods should be spec'd or how the implementations should behave.

> 
>>> But the possibility of CME has to be allowed for in the spec of the interfaced methods regardless.
>>> 
>> 
>> Ideally by not say anything :-) otherwise perhaps a variant of the following:
> 
> Not saying anything doesn't permit CME to be thrown.
> 

Yeah, it was my poor attempt at a joke wishing CME would go away :-)


>> "If a function value passed to an operation of a non-concurrent map modifies the contents of that map then the result of that operation is undefined.  An implementation may throw {@link ConcurrentModificationException} in such cases and if so that behaviour should be documented."
> 
> I don't think it is the Java spirit to allow for undefined behaviour.

OK.


> Wouldn't:
> 
> @throws CME if the <function> modifies the map and this is detected by the implementation
> 
> give the same flexibility while not being so obviously flimsy?

Reluctantly yes; i know it's more of a style thing but it is somewhat tiresome for each and every method receiving a function value to repeat the same thing.

Paul.

>  I prefer to see exception info on methods as much as practical - with NPE being the obvious exception (no pun intended).
>