Collectors update redux

Kevin Bourrillion kevinb at
Thu Feb 7 14:24:24 PST 2013

Okay, I got a presentation over with that was stressing me out and returned
to this. :-)  I think I've spoken too broadly and been unfair to a degree.
 I'll start a new thread soon with a more constructive approach.

On Thu, Feb 7, 2013 at 12:25 PM, Kevin Bourrillion <kevinb at>wrote:

> On Thu, Feb 7, 2013 at 11:34 AM, Brian Goetz <brian.goetz at>wrote:
>  I think there is *way* too much stuff in there, and I don't have enough
>>> time to even review it all before it gets set in stone.
>> "Too much stuff here" is kind of vague.
>> Is the concern that some of the operations (e.g., partition) are just too
>> niche to carry their weight?  Or not fully baked as concepts?
>> Or are some so obvious that we just expect people to write it themselves
>> if they need it?
>> Is the concern that there are too many forms of each operation, and that
>> the user will be bewildered by the variety?
>> Is it the complex interaction of {concurrent, ordered}?
>> Can you point to a few examples of methods you would eliminate?  Maybe we
>> can induct to a pattern from there.
> So... This illustrates the problem I'm talking about.
> You're implying "we need a specific argument to justify leaving X out" and
> the further implication is that if you feel you can refute that argument,
> it stays in. That's the opposite of how it works in my project ... and we
> actually get to remove our mistakes later!
> Did I miss all the discussions where each of the 40 (!) static Collectors
> provided was carefully considered on its merits?
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at

Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at

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