Updated SotL/L documents for Iteration 2

Raab, Donald Donald.Raab at gs.com
Wed Sep 12 21:55:01 PDT 2012

We released GS Collections 2.0 a few weeks ago on GitHub and it includes an approach to primitives similar to what you describe below Brian.


You'll find IntIterable, LongIterable, FloatIterable and DoubleIterable in this package.  

You get to these iterables through the LazyIterable api by calling collect{Int|Long|Float|Double} with the appropriate {Int|Long|Float|Double}Function.


We also added short-cuts for sumOf{Int|Long|Float|Double} on RichIterable.

We've updated the GS Collections Kata to use the new initial primitive support available in GSC 2.0 to illustrate some of the benefits.

You can see some of the differences in results leveraging Java 8 w/ GSC 2.0 primitive support below.

Current using sumOfDouble:

Previous using primitive injectInto:

Current using collectDouble:

Previous using boxed Doubles:

We are working on adding primitive Lists, Sets, Bags, Stacks, Maps to round out the primitive support in GS Collections.  We're also deciding how much additional API we would like to support on the current primitive Iterables.  We should be adding select, reject, detect soon and will be deciding what other API we would like to carry over from RichIterable.

The total surface area for a Java collections library with support for both object and primitive collections with a rich fluent API is certainly non-trivial.

> -----Original Message-----
> From: lambda-libs-spec-experts-bounces at openjdk.java.net [mailto:lambda-
> libs-spec-experts-bounces at openjdk.java.net] On Behalf Of Brian Goetz
> Sent: Monday, September 10, 2012 3:25 PM
> To: Remi Forax
> Cc: lambda-libs-spec-experts at openjdk.java.net
> Subject: Re: Updated SotL/L documents for Iteration 2
> That's something we need to discuss.
> In the past, we outlined a few strategies for getting to primitive
> support:
>   - Primitive specialization of streams (e.g., IntStream) with
> overloads like map(IntMapper) -> yields IntStream.  We'd probably just
> do Int/Long/Double.
>   - VM magic to make boxing costs go away (and give ponies to all the
> children of the world)
>   - Fuse common operations to expose primitive opportunities, like a
> fused mapReduce(IntMapper, IntOperator)
>   - Specialized version of the above, such as sumBy(IntMapper)
>   - Box elimination in libraries (theoretically possible, but probably
> only if pipelines can be precompiled)
> I'm leaning towards preferring the first, because:
>   - It doesn't rely on magic
>   - It lets us expose methods like sum(), max(), min(), and sort() on
> {Int,Long,Double}Stream -- this is a huge plus
>   - It lets us bring more numerics firepower to bear on things like
> DoubleStream.sum()
> Obviously the increased API surface area is a minus.
> On 9/10/2012 2:09 PM, Remi Forax wrote:
> > On 09/10/2012 07:57 PM, Brian Goetz wrote:
> >> Re-sending copies of documents sent last week.
> >>
> >
> > I may be wrong, but there is no mention of primitive specializations.
> > Is it something that is still in flux or not ?
> >
> > Rémi
> >
> >

More information about the lambda-libs-spec-observers mailing list