Loose-ends wrapup

[David M. Lloyd]

On 05/09/2013 02:14 PM, Brian Goetz 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?

Bringing it up for the last time: we should not allow serialization of 
capturing lambdas; instead they should be proactively rejected, as they 
are even less stable than anonymous classes, relying on order of capture 
rather than (at least somewhat semantically relevant) name; representing 
an EE vendor I'm certain we will end up dealing with fallout otherwise.

This is assuming that switching to name-based serialization is still off 
the table, which is also not great but it is at least no worse than what 
we have today.
-- 
- DML