Loose-ends wrapup

[Jim Mayer]

How about a Collectors method that bridges to a Reader?  I'm thinking of
something that worked like a combination of toStringJoiner or to
toStringBuilder and StringStream but that didn't require buffering the
entire output.

A more general bridge to Reader/Writer and IOStream would also be cool,
though one would have to think through how to handle IOException (I'd just
wrap them in a RuntimeException).  That couldn't happen in the case above,
though.

Jim
On May 9, 2013 3:15 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> The majority of the lambda libraries code has been put back to the jdk8
> repositories.  I'm gathering a list of loose ends that we might want to
> circle back to.  The bar for nontrivial new features at this point is high,
> but there are plenty of things in the "small tweaks" category that we can
> do.
>
> There's also lots of work remaining in improving the implementation and
> especially the documentation and specification.  This is a really great
> time to contribute improvements in this area.
>
> Streams -- lingering feature ideas
>
>  - Additional tweaking on range generators (see Paul's emails)
>  - Convenience ints() and longs() generator methods?  (ditto)
>  - Collector for frequency counting?
>  - Support for state-based cancelation (e.g., cancelWhen(BooleanSupplier))
>  - Support for content-based limiting (takeWhile, skipUntil)
>  - Convenience methods like toList() on Stream
>
> SAMs
>  - Additional static or default methods on standard SAMs?
>
> Point lambdafications
>  - Gotta be more of these?
>
> Helper classes
>  - (I hesitate to even suggest): Optional.{filter,map,flatMap}
>    Now that Stream.flatMap is settled, it becomes reasonable to consider
> these.
>
> What others have I missed?
>
>
>
>