Implement CollectorBuilder

[amaembo]

There's an idea for fluent CollectorBuilder which is similar to Stream API itself. Along with OptionalCollector (see #87) it makes complex nested collectors easier to read:

Map<Integer, List<String>> res = IntStreamEx.range(22).boxed().into(
        c -> c.groupingBy(x -> x / 10, 
            c1 -> c1.flatMap(x -> StreamEx.of(x, x*2)).map(x -> "[" + x + "]").limit(5).toList()));
// group by and for each group select at most 5 elements after flatMap and map operations

Map<Boolean, List<Integer>> res3 = IntStreamEx.range(100).boxed().into(c -> c
        .partitioningBy(x -> x % 2 == 0, c1 -> c1.limit(2).toList()));
// select at most two even and two odd numbers (short-circuiting collector)

Such API would be a very complex feature, thus careful evaluation is necessary. Also current attempts show that Eclipse Luna has bad times compiling such things (Eclipse Mars.2 works fine). Probably Luna compiler should be dropped in favor of this feature.

[lukaseder]

Eclipse Luna had tons of Java 8 compiler bugs and performance issues - you should really upgrade. But sooner or later, you'll inevitably run into this show stopper here for Eclipse Mars, too:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=476718

Hmm, how does StreamEx.into(c -> c.xxx) beat StreamEx.collect(Collectors.xxx)?

[amaembo]

Mars.1 was worse than latest Luna updates: many things which worked in Luna failed in Mars.1 (we even experienced ECJ stuck in endless loop). Mars.2 seems to be ok now. Dropping Luna means that not only me should upgrade, but also every user of StreamEx (at least if he wants to use this feature).

The into is better when you need complex combinators. For example, in the first (quite artificial) sample we have

c -> c.groupingBy(x -> x / 10, 
      c1 -> c1.flatMap(x -> StreamEx.of(x, x*2)).map(x -> "[" + x + "]").limit(5).toList())

Currently existing equivalent is

Collectors.groupingBy(x -> x / 10,
    MoreCollectors.flatMapping(x -> StreamEx.of(x, x*2),
        Collectors.mapping(x -> "[" + x + "]", MoreCollectors.head(5))))

I don't like such nesting, it looks ugly. Also it requires various static imports, which I don't like either. In CollectorBuilder version you don't need to specify types at all.

Current implementation is very early draft, so things might change (or I may drop this feature).

[lukaseder]

Dropping Luna means that not only me should upgrade, but also every user of StreamEx (at least if he wants to use this feature).

There's a difference between building StreamEx and using it. Maybe, the issues are internal only?

I see, thanks for the examples. Indeed, there's a certain painpoint. I still find Collectors very unintuitive to use, let alone compose. Looking forward to your future research!

[amaembo]

There's a difference between building StreamEx and using it. Maybe, the issues are internal only?

Nope. Internal issues are easy to fix: you can always introduce explicit type parameter, ugly unchecked cast or intermediate variables. Here, unfortunately, problems appear when you start using this API.

[lukaseder]

Very interesting. Have you considered profiling the issue and sending a bug report to Eclipse? If there's a low hanging fruit, they tend to fix things rather quickly in this area...

[amaembo]

As I said, it's moreless ok in Mars.2 and they will unlikely to backport fixes to Luna. I actually reported a couple of compiler bugs to Eclipse (1, 2).