Extending Collector to handle a post-transform

Brian Goetz brian.goetz at oracle.com
Wed May 29 08:06:37 PDT 2013

I get the "that could be scary" reaction, but let's be more explicit about who has to deal with what incremental complexity.  

Most people will not write Collectors; most collectors that are used will have been written by Kevin or I.  

The proposed functionality would NOT affect any user code.  Most users use canned collectors.  The user could would look like:


in either case.  

Where this intrudes is that the static method toList() in Collectors returns a Collector<T, List<T>, List<T>> instead of Collector<T, List<T>>.  That's the extent of the intrusion.  Its not wonderful, but its not quite as awful as you make it sound.  

I agree that we should try to hide this where possible.  I tried several ways of doing this, but the combinators -- the ones that take a Collector and return a new Collector -- which are most of the reason for being for this API -- are the issue.  We'd need a 2x explosion in the groupingBy combinators, and we just did a LOT of work to get the size of that set down.  

So, can we be a bit more explicit about what you're scared that users will be scared by?  Maybe its not so scary.

On May 29, 2013, at 6:57 AM, Tim Peierls wrote:

> On Tue, May 28, 2013 at 5:59 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> Overall I think this is a reasonable price to pay for making the abstraction more powerful.
> For me, this tips over into unacceptable territory. It's a lot of API complexity that most of the time wouldn't be used, so users would be grappling with an extra type parameter unnecessarily. I think people are going to be confused enough already by things like groupingBy; adding post-transform would put even the simplest usage examples out of reach of ordinary users.
> If post-collect transformation is truly essential, I'd even go for having two variants of each method that currently takes a Collector, one to take non-post-transforming Collector<T, R> and one to take CollectorAndTransformer<T, X, R>. I don't love adding methods, but at least that way regular users could avoid the scary version.
> --tim

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