hg: lambda/lambda/jdk: bug fixes and unit test for Map Defaults
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
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
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lambda-libs-spec-experts