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

Joe Bowbeer joe.bowbeer at gmail.com
Thu Mar 28 07:15:18 PDT 2013


What about #2 which lists two options?

I think we should choose one or the other option. We shouldn't choose the
middle ground without changing the description, which would remove the
middle ground.
On Mar 28, 2013 5:22 AM, "Doug Lea" <dl at cs.oswego.edu> wrote:

> On 03/28/13 00:51, Joe Bowbeer wrote:
>
>> The way I'm interpreting this is:
>>
>> 1. ConcurrentMap effectively prohibits nulls (feel free to make analogies
>> with
>> effective thread safety;)
>>
>
> No, it has exactly the same issues as the added Map methods.
> If you use it with a null-value-accepting Map, then it
> does something that meets spec, but that something might not
> be what you have in mind.
>
> Backing up: the reason these are added to Map is that without
> them, streams can't reasonably implement map-related collect
> operations. Would you rather we kill them? And it is
> not just Streams; no one else can write them either without
> knowing exactly which concrete Map class they have.
>
> This is one of the reasons I ranted so much last year about
> why banishing nulls from streams was simplest path to
> API sanity. That is, if we can't banish them from
> Collections/Maps, we could at least do so as stream
> sources/destinations. Given that we didn't do this,
> there's a continual set of subsidiary issues like this
> one.
>
> -Doug
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130328/36883c7d/attachment.html 


More information about the lambda-libs-spec-experts mailing list