hg: lambda/lambda/jdk: 3 new changesets

[Brian Goetz]

> I don't like the class StringJoiner because despite the fact it's a
> reduce operation,
> it's implemented as a Fillable, so something eager which will not work
> as is in the parallel world.

That's where we started -- trying to treat string joining as a reduce. 
But because String is immutable, doing a sequential reduce with string 
concatenation becomes an O(n^2) operation, which is not good.

(Originally we thought that the way to do joining was:
    stream.interleaveWith(Streams.repeating(", "))
          .reduce(String::concatenate)
but the reduce step, which, while pretty, was inefficient.)

The parallel case isn't much better.  Even if you do a number of string 
joins at the leaves of the tree, the top-level combine still has to copy 
all the string content, which loses most of the parallelism.

But you can still do upstream ops in parallel:

   collection.parallel()
             .filter(...)
             .map(...)
             .sorted()
             .sequential()
             .into(new StringJoiner(", "));

and all the upstream stuff will happen in parallel.

> I think it's better to add join() on Iterable.

Would like to, but we can't add methods that only apply to specific 
parameterizations.