Refactor of Collector interface

Kevin Bourrillion kevinb at
Fri Feb 8 09:30:45 PST 2013

On Fri, Feb 8, 2013 at 9:13 AM, Tim Peierls <tim at> wrote:

My subjective sense of good Java API design very strongly prefers the
>> "before" picture here, which I see as a lot more "Java-like", so I'm taking
>> a closer look.
> The before picture is certainly more pre-lambda-Java-like, but I don't
> think it's fair to knock something meant to fit well with a new language
> feature by those rules.

I think I'm only really saying the same thing Brian is when he says "While
clearly we don't want all interfaces to evolve this way..." and "while I
don't feel completely super-great about it....", etc.

I'd prefer to not rely on the taste argument if we can treat the benefits

> I thought the return types of the after picture conveyed more clearly the
> idea of "I'm going to need a way to supply result objects, and way to
> accumulate elements into result objects, and a way to combine result
> objects."  And seeing those interface types as return types reinforced my
> understanding of those types.
> I assume that the trade-offs we're weighing here are purely to do with
>> what it's like to be a Collector implementor, correct?
> Well, since I persist in preferring the after picture -- maybe the
> impending blizzard has addled my senses -- I'd say the benefit to Collector
> implementers is secondary.
> --tim

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

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