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

Doug Lea dl at cs.oswego.edu
Wed Oct 16 11:58:47 UTC 2013


On 10/16/2013 07:26 AM, Paul Sandoz wrote:
>
> On Oct 16, 2013, at 12:28 PM, David Holmes <david.holmes at oracle.com> wrote:
>
>> On 16/10/2013 8:03 PM, Paul Sandoz wrote:
>>>
>>> HashMap.compute*/merge methods do not throw CME either. I suppose those
>>> methods could and do so beyond that of only the entry under computation.
>>> I think this really points to the fact that, for non-traversal, only
>>> concrete implementations are capable of reliably detecting a CME and
>>> therefore it's best to leave it up to those implementations should they
>>> choose to do so.
>>
>> 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.
>
>
>> But the possibility of CME has to be allowed for in the spec of the
>> interfaced methods regardless.
>>
>

A variant of this issue came up a year or so ago for
JDK8 ConcurrentHashMap.compute*/merge: What happens if
the lambda side-effects by modifying some other
map element? Because CHM (sometimes) uses fine-grained
locks, it is possible for two such operations from
different threads could cause a deadlock. We put in
wording saying that the methods are allowed to throw
exceptions in this case (rather than deadlock) but
they currently don't catch all such errors. Which seems
analogous to the non-concurrent case, so maybe similar
wording could be used at Map level.

CHM:
      * @throws IllegalStateException if the computation detectably
      *         attempts a recursive update to this map that would
      *         otherwise never complete

Map?
      * @throws IllegalStateException if the computation detectably
      *         attempts a secondary update to this map that would
      *         otherwise never complete or perform an inconsistent update


-Doug




More information about the core-libs-dev mailing list