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

Paul Sandoz paul.sandoz at oracle.com
Mon Oct 14 09:32:25 UTC 2013


On Oct 11, 2013, at 9:46 PM, Mike Duigou <mike.duigou at oracle.com> wrote:

> 
> On Oct 10 2013, at 06:37 , Paul Sandoz wrote:
> 
>> Hi Mike,
>> 
>> This looks like a good direction. Need to look more closely.
>> 
>> I wonder if we even require such detailed support to throw CME? 
> 
> Some additional CME will be thrown indirectly by iteration. This applies to forEach/replaceAll.

Yes, that is OK (catching IllegalStateException). It is the explicit cases in other non-traversing methods i am referring to.


> 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.


>> 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.

Paul.

> Any thoughts Doug? Is this advancing or retreating from the right direction?
> 
> Mike



More information about the core-libs-dev mailing list