Zipping Steams...
Sam Pullara
spullara at gmail.com
Mon Jan 13 14:41:32 PST 2014
Send me your github names and I will make one and add you as committers.
Sam
> On Jan 13, 2014, at 11:33 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
>> On Jan 13, 2014, at 7:25 PM, Brent Walker <brenthwalker at gmail.com> wrote:
>> Thank you for pointing out the error in our ways. Here is your code updated so that it compiles with the current state of the API. (StreamSupport.parallelStream() does not exist anymore, Streams.NONE also not there).
>
> Yeah, you can tell i copied that from some cache and neglected to update it :-)
>
>
>> Since Streams.NONE was not there, I modified tryAdvance() to use the continuation passing style we had in our solution and got rid of the accept(Object) function. This avoids all the casting, and we can delete Objects "a" and "b" from the Spliterator (which now does not have to be a Consumer<>).
>
> Although that is likely to be not as efficient as reusing the Spliterator instance as the Consumer, which avoids two capturing lambdas per-element and has less layering.
>
>
>> Hopefully hotspot can see throw all the code threading and inline everything.
>
> Perhaps. Hotspot inlining is impressive but lambdas are pushing it the limit and there is definitely room for improvement especially in cases such as tryAdvance or forEachRemaining where call sites can easily go megamorphic. Hence in part to currently put up with the ugliness of casts etc.
>
>
>> Don't you have a place where examples of code can be placed in the jdk?
>
> Nothing official, it would be in the JDK otherwise :-)
>
> Cheekiness aside, i think a github project would be fine, and i would happy to help commit and maintain examples of stuff that nearly but not quite made the cut in the JDK and other informative examples. Wanna create one?
>
> Paul.
>
More information about the lambda-dev
mailing list