Updated SotL/L documents for Iteration 2

[Brian Goetz]

Duh, I forgot attachments are not permitted on this list :(

I sent them to lambda-libs-spec-experts, you can see the mangled version 
of the attachments here:
 
http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2012-September/000000.html

Meanwhile I'll come up with a better place to stash them.

On 9/10/2012 1:51 PM, Brian Goetz wrote:
> We're now almost finished prototyping Iteration 2 of the Lambda
> Libraries APIs; they are still in an experimental branch in the openjdk
> lambda repo (it2-bootstrap), but will be moved into the default branch
> (still of the lambda repo) in the next few days.
>
> The attached documents describe the approach taken in Iteration 2, and
> the changes since Iteration 1.  There are still plenty of open issues to
> discuss, and I'll be discussing them on the EG list.
>
> Several significant API changes between Iterations 1 and 2:
>    - In Iteration 1, stream operations were injected directly into
> Iterable; now Stream is its own entity, which is much more like an
> Iterator rather than an Iterable.
>    - There are now stream "accessor" methods on Collection and friends;
> instead of sayng collection.filter(...)..., you now have to say
> collection.stream().filter(...) or collection.parallel().filter(...).
>    - The multiplicity of interfaces (Stream, StreamOps, Streamable,
> ParallelStream, ParallelStreamable, etc) has been collapsed
> dramatically, down to one Stream interface for each shape (list-shaped,
> map-shaped).  The serial/parallel-ness of a stream is now a dynamic
> rather than static property.
>    - Most terminal operations are performed by forEach'ing elements into
> a "sink" rather than pulling elements from an Iterator.
>    - There is an extensible API for adding new stream operations besides
> the built-in ones, although this API will likely not be exposed in JDK 8
> (needs more bake time.)
>
> As usual, the implementation and API are in varying states of
> "done"-ness; the general shape and set of operations is fairly baked,
> but many of the implementation details and internal APIs (such as
> StreamAccessor, ParallelOp, ParallelHelper) are mostly stabs in the
> dark, and there are bits we know we have to fix that have just not yet
> been fixed as we've been focusing on the high-order bits.
>
> Start with Stream, MapStream and Streamable -- that's most of the
> exposed API right there (and the most baked part.)
>
>
>
>