hg: lambda/lambda/jdk: bug fixes and unit test for Map Defaults

[Joe Bowbeer]

The way I'm interpreting this is:

1. ConcurrentMap effectively prohibits nulls (feel free to make analogies
with effective thread safety;)

2. Map is not. It accommodates nulls.

I'm not happy with this current middle ground taken by Map's putIfAbsent. I
think it either needs to (1) accommodate nulls to the extent that it can,
according to the letter of the current definition, which leaves the return
value useless, or (2) we should redefine putIfAbsent, removing the
!contains part and substituting get==null.

As it stands, I can't figure out what it does without legacy information
and implementation details, which is not satisfying.
On Mar 27, 2013 10:35 AM, "Doug Lea" <dl at cs.oswego.edu> wrote:

> On 03/27/13 11:45, Joe Bowbeer wrote:
>
>> putIfAbsent was not designed to be compatible with null values. It was
>> designed
>> for the null-incompatible ConcurrentMap interface. I don't think a
>> null-compatible implementation of CM is possible, BTW.
>>
>>
> This is what everyone mis-remembers. Somehow I let someone talk
> me into not strictly banishing nulls in ConcurrentMap interface
> specs, even though some methods are not very useful if they are
> allowed, and no actual implementation I know allows them.
>
> The defaults for the new stream-collect-friendly Map methods
> preserve this state of affairs.
>
> -Doug
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130328/f3b9d272/attachment.html