Collectors update redux

[Kevin Bourrillion]

On Thu, Feb 7, 2013 at 11:34 AM, Brian Goetz <brian.goetz at oracle.com> 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 google.com