From joe.bowbeer at gmail.com  Mon Sep  2 09:15:09 2013
From: joe.bowbeer at gmail.com (Joe Bowbeer)
Date: Mon, 2 Sep 2013 09:15:09 -0700
Subject: Specs
In-Reply-To: <521E7269.6010502@oracle.com>
References: <521E7269.6010502@oracle.com>
Message-ID: <CAHzJPEpEcHajHNiE5JXCo2Wfm57GxcfGTjM9s2u-m9XZo7-v2w@mail.gmail.com>

I just sent Brian comments on the package description and the BaseStream
family of interfaces.

Overall, I like the way this is coming together.  The package description
is substantial, but it's worth the programmer's time.  The references to
package-description in the Stream methods are effective.  Hey, I *feel*
like I understand.

However, there's plenty of room for improvement.  I'd be happy to send my
detailed review - or a simplified summary - to this list if there is
interest.

--Joe


On Wed, Aug 28, 2013 at 2:58 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Have I mentioned that reviews of the specs and package doc at:
>
>   http://cr.openjdk.java.net/~**briangoetz/doctmp/doc/<http://cr.openjdk.java.net/~briangoetz/doctmp/doc/>
>
> would be appreciated?
>
>

From martijnverburg at gmail.com  Mon Sep  2 10:11:38 2013
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 2 Sep 2013 18:11:38 +0100
Subject: Specs
In-Reply-To: <CAHzJPEpEcHajHNiE5JXCo2Wfm57GxcfGTjM9s2u-m9XZo7-v2w@mail.gmail.com>
References: <521E7269.6010502@oracle.com>
	<CAHzJPEpEcHajHNiE5JXCo2Wfm57GxcfGTjM9s2u-m9XZo7-v2w@mail.gmail.com>
Message-ID: <CAP7YuAQi7NqV6x2vsTyVup0DYHjScmCXzopNNAy0mErGS_ah4A@mail.gmail.com>

Hi Joe,

If you could send them to the list that would be great, saves making
duplicate comments (if any).

Cheers,
Martijn


On 2 September 2013 17:15, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> I just sent Brian comments on the package description and the BaseStream
> family of interfaces.
>
> Overall, I like the way this is coming together.  The package description
> is substantial, but it's worth the programmer's time.  The references to
> package-description in the Stream methods are effective.  Hey, I *feel*
> like I understand.
>
> However, there's plenty of room for improvement.  I'd be happy to send my
> detailed review - or a simplified summary - to this list if there is
> interest.
>
> --Joe
>
>
> On Wed, Aug 28, 2013 at 2:58 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
> > Have I mentioned that reviews of the specs and package doc at:
> >
> >   http://cr.openjdk.java.net/~**briangoetz/doctmp/doc/<
> http://cr.openjdk.java.net/~briangoetz/doctmp/doc/>
> >
> > would be appreciated?
> >
> >
>

From spullara at gmail.com  Mon Sep  2 10:19:05 2013
From: spullara at gmail.com (Sam Pullara)
Date: Mon, 2 Sep 2013 10:19:05 -0700
Subject: Interesting inference case
Message-ID: <50000D4B-27C5-4878-BDB5-88434FE18A32@gmail.com>

I was trying to pass Semaphore::release to ExecutorService.submit and ran into a puzzling compile error. Here is a reproduction case:

public class InferTest {
    void call() {}
//    void call(int i) {}

    @Test
    public void test() {
        ExecutorService es = Executors.newCachedThreadPool();
        es.submit(this::call);
    }
}

With the comment, this compiles fine. If you uncomment the second call() method it fails with:

java: reference to submit is ambiguous
  both method <T>submit(java.util.concurrent.Callable<T>) in java.util.concurrent.ExecutorService and method submit(java.lang.Runnable) in java.util.concurrent.ExecutorService match
java: incompatible types: cannot infer type-variable(s) T
    (argument mismatch; bad return type in method reference
      void cannot be converted to T)

I'm not sure why the overload on call() would cause the ambiguity. 

Sam


From joe.bowbeer at gmail.com  Mon Sep  2 11:13:38 2013
From: joe.bowbeer at gmail.com (Joe Bowbeer)
Date: Mon, 2 Sep 2013 11:13:38 -0700
Subject: Interesting inference case
In-Reply-To: <50000D4B-27C5-4878-BDB5-88434FE18A32@gmail.com>
References: <50000D4B-27C5-4878-BDB5-88434FE18A32@gmail.com>
Message-ID: <CAHzJPEr0=QfHPfAwbdvqUfE6rRy6kQ-Na9Sq2NF_VHFHSSTgog@mail.gmail.com>

Suppose you comment out call() instead, then does it also not complain?

Without call(i), this resolves to ES.submit(Runnable) ?

But with call(i) it could also resolve to ES.submit(Callable) ?

Intuitively, I would expect it to prefer a Callable to a Runnable given the
match in method name...




On Mon, Sep 2, 2013 at 10:19 AM, Sam Pullara <spullara at gmail.com> wrote:

> I was trying to pass Semaphore::release to ExecutorService.submit and ran
> into a puzzling compile error. Here is a reproduction case:
>
> public class InferTest {
>     void call() {}
> //    void call(int i) {}
>
>     @Test
>     public void test() {
>         ExecutorService es = Executors.newCachedThreadPool();
>         es.submit(this::call);
>     }
> }
>
> With the comment, this compiles fine. If you uncomment the second call()
> method it fails with:
>
> java: reference to submit is ambiguous
>   both method <T>submit(java.util.concurrent.Callable<T>) in
> java.util.concurrent.ExecutorService and method submit(java.lang.Runnable)
> in java.util.concurrent.ExecutorService match
> java: incompatible types: cannot infer type-variable(s) T
>     (argument mismatch; bad return type in method reference
>       void cannot be converted to T)
>
> I'm not sure why the overload on call() would cause the ambiguity.
>
> Sam
>
>

From tim at peierls.net  Mon Sep  2 11:42:21 2013
From: tim at peierls.net (Tim Peierls)
Date: Mon, 2 Sep 2013 14:42:21 -0400
Subject: Specs
In-Reply-To: <CAHzJPEpEcHajHNiE5JXCo2Wfm57GxcfGTjM9s2u-m9XZo7-v2w@mail.gmail.com>
References: <521E7269.6010502@oracle.com>
	<CAHzJPEpEcHajHNiE5JXCo2Wfm57GxcfGTjM9s2u-m9XZo7-v2w@mail.gmail.com>
Message-ID: <CA+F8eeR+0ih-YvGrOGSnkq_wPGEwvJT+=ggfMkRRcqQu6B3-ww@mail.gmail.com>

I sent Brian comments on the package summary a couple of days ago. I am
curious to see whether there's any overlap or disagreement between what Joe
wrote and what I wrote, but I'm sort of hoping Brian will summarize all of
the responses rather than having to wade through them myself. (Yes, I know
that just adds to Brian's work pile, but some sort of summary will be
needed in any case.)

--tim


On Mon, Sep 2, 2013 at 12:15 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> I just sent Brian comments on the package description and the BaseStream
> family of interfaces.
>
> Overall, I like the way this is coming together.  The package description
> is substantial, but it's worth the programmer's time.  The references to
> package-description in the Stream methods are effective.  Hey, I *feel*
> like I understand.
>
> However, there's plenty of room for improvement.  I'd be happy to send my
> detailed review - or a simplified summary - to this list if there is
> interest.
>
> --Joe
>
>
> On Wed, Aug 28, 2013 at 2:58 PM, Brian Goetz <brian.goetz at oracle.com>wrote:
>
>> Have I mentioned that reviews of the specs and package doc at:
>>
>>   http://cr.openjdk.java.net/~**briangoetz/doctmp/doc/<http://cr.openjdk.java.net/~briangoetz/doctmp/doc/>
>>
>> would be appreciated?
>>
>>
>

From spullara at gmail.com  Mon Sep  2 12:15:35 2013
From: spullara at gmail.com (Sam Pullara)
Date: Mon, 2 Sep 2013 12:15:35 -0700
Subject: Interesting inference case
In-Reply-To: <CAHzJPEr0=QfHPfAwbdvqUfE6rRy6kQ-Na9Sq2NF_VHFHSSTgog@mail.gmail.com>
References: <50000D4B-27C5-4878-BDB5-88434FE18A32@gmail.com>
	<CAHzJPEr0=QfHPfAwbdvqUfE6rRy6kQ-Na9Sq2NF_VHFHSSTgog@mail.gmail.com>
Message-ID: <5CB54D8E-0E69-4649-A442-8781D657779C@gmail.com>

The funny thing is, call(int i) is not a valid match for either Runnable or Callable. You're thinking "int call()" which would match Callable.

Sam

On Sep 2, 2013, at 11:13 AM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> Suppose you comment out call() instead, then does it also not complain?
> 
> Without call(i), this resolves to ES.submit(Runnable) ?
> 
> But with call(i) it could also resolve to ES.submit(Callable) ?
> 
> Intuitively, I would expect it to prefer a Callable to a Runnable given the match in method name...
> 
> 
> 
> 
> On Mon, Sep 2, 2013 at 10:19 AM, Sam Pullara <spullara at gmail.com> wrote:
> I was trying to pass Semaphore::release to ExecutorService.submit and ran into a puzzling compile error. Here is a reproduction case:
> 
> public class InferTest {
>     void call() {}
> //    void call(int i) {}
> 
>     @Test
>     public void test() {
>         ExecutorService es = Executors.newCachedThreadPool();
>         es.submit(this::call);
>     }
> }
> 
> With the comment, this compiles fine. If you uncomment the second call() method it fails with:
> 
> java: reference to submit is ambiguous
>   both method <T>submit(java.util.concurrent.Callable<T>) in java.util.concurrent.ExecutorService and method submit(java.lang.Runnable) in java.util.concurrent.ExecutorService match
> java: incompatible types: cannot infer type-variable(s) T
>     (argument mismatch; bad return type in method reference
>       void cannot be converted to T)
> 
> I'm not sure why the overload on call() would cause the ambiguity.
> 
> Sam
> 
> 


From brian.goetz at oracle.com  Tue Sep  3 11:37:49 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 03 Sep 2013 14:37:49 -0400
Subject: Specs
In-Reply-To: <CA+F8eeR+0ih-YvGrOGSnkq_wPGEwvJT+=ggfMkRRcqQu6B3-ww@mail.gmail.com>
References: <521E7269.6010502@oracle.com>
	<CAHzJPEpEcHajHNiE5JXCo2Wfm57GxcfGTjM9s2u-m9XZo7-v2w@mail.gmail.com>
	<CA+F8eeR+0ih-YvGrOGSnkq_wPGEwvJT+=ggfMkRRcqQu6B3-ww@mail.gmail.com>
Message-ID: <52262C7D.8070900@oracle.com>

Plowing through all of these today...I've got just about all the 
directly actionable ones processed, stumbling a bit on the less 
actionable ones (e.g., "This section needs work.")

I've updated the docs at the temporary site.

Old docs: http://cr.openjdk.java.net/~briangoetz/doctmp/doc0
New docs: http://cr.openjdk.java.net/~briangoetz/doctmp/doc1

And posted a "specdiff" between them at:
   http://cr.openjdk.java.net/~briangoetz/doctmp/diff1




On 9/2/2013 2:42 PM, Tim Peierls wrote:
> I sent Brian comments on the package summary a couple of days ago. I am
> curious to see whether there's any overlap or disagreement between what
> Joe wrote and what I wrote, but I'm sort of hoping Brian will summarize
> all of the responses rather than having to wade through them myself.
> (Yes, I know that just adds to Brian's work pile, but some sort of
> summary will be needed in any case.)
>
> --tim
>
>
> On Mon, Sep 2, 2013 at 12:15 PM, Joe Bowbeer <joe.bowbeer at gmail.com
> <mailto:joe.bowbeer at gmail.com>> wrote:
>
>     I just sent Brian comments on the package description and the
>     BaseStream family of interfaces.
>
>     Overall, I like the way this is coming together.  The package
>     description is substantial, but it's worth the programmer's time.
>       The references to package-description in the Stream methods are
>     effective.  Hey, I *feel* like I understand.
>
>     However, there's plenty of room for improvement.  I'd be happy to
>     send my detailed review - or a simplified summary - to this list if
>     there is interest.
>
>     --Joe
>
>
>     On Wed, Aug 28, 2013 at 2:58 PM, Brian Goetz <brian.goetz at oracle.com
>     <mailto:brian.goetz at oracle.com>> wrote:
>
>         Have I mentioned that reviews of the specs and package doc at:
>
>         http://cr.openjdk.java.net/~__briangoetz/doctmp/doc/
>         <http://cr.openjdk.java.net/~briangoetz/doctmp/doc/>
>
>         would be appreciated?
>
>
>

From spullara at gmail.com  Tue Sep  3 11:50:08 2013
From: spullara at gmail.com (Sam Pullara)
Date: Tue, 3 Sep 2013 11:50:08 -0700
Subject: Specs
In-Reply-To: <52262C7D.8070900@oracle.com>
References: <521E7269.6010502@oracle.com>
	<CAHzJPEpEcHajHNiE5JXCo2Wfm57GxcfGTjM9s2u-m9XZo7-v2w@mail.gmail.com>
	<CA+F8eeR+0ih-YvGrOGSnkq_wPGEwvJT+=ggfMkRRcqQu6B3-ww@mail.gmail.com>
	<52262C7D.8070900@oracle.com>
Message-ID: <FA7A6351-3496-48B8-A9C1-F7570A6380AE@gmail.com>

I still don't think there is sufficient explanation of the motivations around why someone would use parallel() and what the performance implications of using it might be. 

Sam

On Sep 3, 2013, at 11:37 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Plowing through all of these today...I've got just about all the directly actionable ones processed, stumbling a bit on the less actionable ones (e.g., "This section needs work.")
> 
> I've updated the docs at the temporary site.
> 
> Old docs: http://cr.openjdk.java.net/~briangoetz/doctmp/doc0
> New docs: http://cr.openjdk.java.net/~briangoetz/doctmp/doc1
> 
> And posted a "specdiff" between them at:
>  http://cr.openjdk.java.net/~briangoetz/doctmp/diff1
> 
> 
> 
> 
> On 9/2/2013 2:42 PM, Tim Peierls wrote:
>> I sent Brian comments on the package summary a couple of days ago. I am
>> curious to see whether there's any overlap or disagreement between what
>> Joe wrote and what I wrote, but I'm sort of hoping Brian will summarize
>> all of the responses rather than having to wade through them myself.
>> (Yes, I know that just adds to Brian's work pile, but some sort of
>> summary will be needed in any case.)
>> 
>> --tim
>> 
>> 
>> On Mon, Sep 2, 2013 at 12:15 PM, Joe Bowbeer <joe.bowbeer at gmail.com
>> <mailto:joe.bowbeer at gmail.com>> wrote:
>> 
>>    I just sent Brian comments on the package description and the
>>    BaseStream family of interfaces.
>> 
>>    Overall, I like the way this is coming together.  The package
>>    description is substantial, but it's worth the programmer's time.
>>      The references to package-description in the Stream methods are
>>    effective.  Hey, I *feel* like I understand.
>> 
>>    However, there's plenty of room for improvement.  I'd be happy to
>>    send my detailed review - or a simplified summary - to this list if
>>    there is interest.
>> 
>>    --Joe
>> 
>> 
>>    On Wed, Aug 28, 2013 at 2:58 PM, Brian Goetz <brian.goetz at oracle.com
>>    <mailto:brian.goetz at oracle.com>> wrote:
>> 
>>        Have I mentioned that reviews of the specs and package doc at:
>> 
>>        http://cr.openjdk.java.net/~__briangoetz/doctmp/doc/
>>        <http://cr.openjdk.java.net/~briangoetz/doctmp/doc/>
>> 
>>        would be appreciated?
>> 
>> 
>> 


From brian.goetz at oracle.com  Tue Sep  3 11:52:24 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 03 Sep 2013 14:52:24 -0400
Subject: Specs
In-Reply-To: <FA7A6351-3496-48B8-A9C1-F7570A6380AE@gmail.com>
References: <521E7269.6010502@oracle.com>
	<CAHzJPEpEcHajHNiE5JXCo2Wfm57GxcfGTjM9s2u-m9XZo7-v2w@mail.gmail.com>
	<CA+F8eeR+0ih-YvGrOGSnkq_wPGEwvJT+=ggfMkRRcqQu6B3-ww@mail.gmail.com>
	<52262C7D.8070900@oracle.com>
	<FA7A6351-3496-48B8-A9C1-F7570A6380AE@gmail.com>
Message-ID: <52262FE8.4040304@oracle.com>

Agreed.  We need to do more to seed the user's mental cost model, so 
they can reason about what is likely to be faster or slower.

So, what should we be saying, and where should it be said?  Clearly we 
can talk some in the "Parallelism" section.  Also, I think we should 
have some @implNote for some of the problematic operations, such as 
limit, where we describe the cases that work really well (e.g., parallel 
limit works great on SUBSIZED sources) or not so well (groupingBy with 
HashMap sucks in parallel, due to expensive merge.)

On 9/3/2013 2:50 PM, Sam Pullara wrote:
> I still don't think there is sufficient explanation of the motivations around why someone would use parallel() and what the performance implications of using it might be.
>
> Sam
>
> On Sep 3, 2013, at 11:37 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>> Plowing through all of these today...I've got just about all the directly actionable ones processed, stumbling a bit on the less actionable ones (e.g., "This section needs work.")
>>
>> I've updated the docs at the temporary site.
>>
>> Old docs: http://cr.openjdk.java.net/~briangoetz/doctmp/doc0
>> New docs: http://cr.openjdk.java.net/~briangoetz/doctmp/doc1
>>
>> And posted a "specdiff" between them at:
>>   http://cr.openjdk.java.net/~briangoetz/doctmp/diff1
>>
>>
>>
>>
>> On 9/2/2013 2:42 PM, Tim Peierls wrote:
>>> I sent Brian comments on the package summary a couple of days ago. I am
>>> curious to see whether there's any overlap or disagreement between what
>>> Joe wrote and what I wrote, but I'm sort of hoping Brian will summarize
>>> all of the responses rather than having to wade through them myself.
>>> (Yes, I know that just adds to Brian's work pile, but some sort of
>>> summary will be needed in any case.)
>>>
>>> --tim
>>>
>>>
>>> On Mon, Sep 2, 2013 at 12:15 PM, Joe Bowbeer <joe.bowbeer at gmail.com
>>> <mailto:joe.bowbeer at gmail.com>> wrote:
>>>
>>>     I just sent Brian comments on the package description and the
>>>     BaseStream family of interfaces.
>>>
>>>     Overall, I like the way this is coming together.  The package
>>>     description is substantial, but it's worth the programmer's time.
>>>       The references to package-description in the Stream methods are
>>>     effective.  Hey, I *feel* like I understand.
>>>
>>>     However, there's plenty of room for improvement.  I'd be happy to
>>>     send my detailed review - or a simplified summary - to this list if
>>>     there is interest.
>>>
>>>     --Joe
>>>
>>>
>>>     On Wed, Aug 28, 2013 at 2:58 PM, Brian Goetz <brian.goetz at oracle.com
>>>     <mailto:brian.goetz at oracle.com>> wrote:
>>>
>>>         Have I mentioned that reviews of the specs and package doc at:
>>>
>>>         http://cr.openjdk.java.net/~__briangoetz/doctmp/doc/
>>>         <http://cr.openjdk.java.net/~briangoetz/doctmp/doc/>
>>>
>>>         would be appreciated?
>>>
>>>
>>>
>

From joe.bowbeer at gmail.com  Tue Sep  3 15:19:54 2013
From: joe.bowbeer at gmail.com (Joe Bowbeer)
Date: Tue, 3 Sep 2013 15:19:54 -0700
Subject: Specs
In-Reply-To: <52262C7D.8070900@oracle.com>
References: <521E7269.6010502@oracle.com>
	<CAHzJPEpEcHajHNiE5JXCo2Wfm57GxcfGTjM9s2u-m9XZo7-v2w@mail.gmail.com>
	<CA+F8eeR+0ih-YvGrOGSnkq_wPGEwvJT+=ggfMkRRcqQu6B3-ww@mail.gmail.com>
	<52262C7D.8070900@oracle.com>
Message-ID: <CAHzJPEpcqGEU8G55kO53VPs4UbsOsdw7_YrqjjMx3XnVd9HvRQ@mail.gmail.com>

My feedback included a couple "needs more work" that were directed at a
specific paragraph in each case.

Let me know if I should submit suggested fixes in these cases.  Thanks.


On Tue, Sep 3, 2013 at 11:37 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Plowing through all of these today...I've got just about all the directly
> actionable ones processed, stumbling a bit on the less actionable ones
> (e.g., "This section needs work.")
>
> I've updated the docs at the temporary site.
>
> Old docs: http://cr.openjdk.java.net/~**briangoetz/doctmp/doc0<http://cr.openjdk.java.net/~briangoetz/doctmp/doc0>
> New docs: http://cr.openjdk.java.net/~**briangoetz/doctmp/doc1<http://cr.openjdk.java.net/~briangoetz/doctmp/doc1>
>
> And posted a "specdiff" between them at:
>   http://cr.openjdk.java.net/~**briangoetz/doctmp/diff1<http://cr.openjdk.java.net/~briangoetz/doctmp/diff1>
>
>
>
>
>
> On 9/2/2013 2:42 PM, Tim Peierls wrote:
>
>> I sent Brian comments on the package summary a couple of days ago. I am
>> curious to see whether there's any overlap or disagreement between what
>> Joe wrote and what I wrote, but I'm sort of hoping Brian will summarize
>> all of the responses rather than having to wade through them myself.
>> (Yes, I know that just adds to Brian's work pile, but some sort of
>> summary will be needed in any case.)
>>
>> --tim
>>
>>
>> On Mon, Sep 2, 2013 at 12:15 PM, Joe Bowbeer <joe.bowbeer at gmail.com
>> <mailto:joe.bowbeer at gmail.com>**> wrote:
>>
>>     I just sent Brian comments on the package description and the
>>     BaseStream family of interfaces.
>>
>>     Overall, I like the way this is coming together.  The package
>>     description is substantial, but it's worth the programmer's time.
>>       The references to package-description in the Stream methods are
>>     effective.  Hey, I *feel* like I understand.
>>
>>     However, there's plenty of room for improvement.  I'd be happy to
>>     send my detailed review - or a simplified summary - to this list if
>>     there is interest.
>>
>>     --Joe
>>
>>
>>     On Wed, Aug 28, 2013 at 2:58 PM, Brian Goetz <brian.goetz at oracle.com
>>     <mailto:brian.goetz at oracle.com**>> wrote:
>>
>>         Have I mentioned that reviews of the specs and package doc at:
>>
>>         http://cr.openjdk.java.net/~__**briangoetz/doctmp/doc/<http://cr.openjdk.java.net/~__briangoetz/doctmp/doc/>
>>
>>         <http://cr.openjdk.java.net/~**briangoetz/doctmp/doc/<http://cr.openjdk.java.net/~briangoetz/doctmp/doc/>
>> >
>>
>>         would be appreciated?
>>
>>
>>
>>

From joe.bowbeer at gmail.com  Tue Sep  3 15:28:26 2013
From: joe.bowbeer at gmail.com (Joe Bowbeer)
Date: Tue, 3 Sep 2013 15:28:26 -0700
Subject: Specs
In-Reply-To: <52262FE8.4040304@oracle.com>
References: <521E7269.6010502@oracle.com>
	<CAHzJPEpEcHajHNiE5JXCo2Wfm57GxcfGTjM9s2u-m9XZo7-v2w@mail.gmail.com>
	<CA+F8eeR+0ih-YvGrOGSnkq_wPGEwvJT+=ggfMkRRcqQu6B3-ww@mail.gmail.com>
	<52262C7D.8070900@oracle.com>
	<FA7A6351-3496-48B8-A9C1-F7570A6380AE@gmail.com>
	<52262FE8.4040304@oracle.com>
Message-ID: <CAHzJPEqjjU1tkc=4+x8hTkFKi=Di7oU1Cw4hA67_q8QMo2HP-A@mail.gmail.com>

The developers who are up on the current trends will already be motivated
for parallel().  The developers who aren't may need a gentle introduction,
but I don't think we need to replicate all of Guy Steele's and Guy
Blelloch's talking points.  Just a summary and a reference?

The other thing that is needed is some explanation and cautions
(implementation notes?) regarding how this implementation differs from the
ideals espoused by the parallel advocates.



On Tue, Sep 3, 2013 at 11:52 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Agreed.  We need to do more to seed the user's mental cost model, so they
> can reason about what is likely to be faster or slower.
>
> So, what should we be saying, and where should it be said?  Clearly we can
> talk some in the "Parallelism" section.  Also, I think we should have some
> @implNote for some of the problematic operations, such as limit, where we
> describe the cases that work really well (e.g., parallel limit works great
> on SUBSIZED sources) or not so well (groupingBy with HashMap sucks in
> parallel, due to expensive merge.)
>
>
> On 9/3/2013 2:50 PM, Sam Pullara wrote:
>
>> I still don't think there is sufficient explanation of the motivations
>> around why someone would use parallel() and what the performance
>> implications of using it might be.
>>
>> Sam
>>
>> On Sep 3, 2013, at 11:37 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>>  Plowing through all of these today...I've got just about all the
>>> directly actionable ones processed, stumbling a bit on the less actionable
>>> ones (e.g., "This section needs work.")
>>>
>>> I've updated the docs at the temporary site.
>>>
>>> Old docs: http://cr.openjdk.java.net/~**briangoetz/doctmp/doc0<http://cr.openjdk.java.net/~briangoetz/doctmp/doc0>
>>> New docs: http://cr.openjdk.java.net/~**briangoetz/doctmp/doc1<http://cr.openjdk.java.net/~briangoetz/doctmp/doc1>
>>>
>>> And posted a "specdiff" between them at:
>>>   http://cr.openjdk.java.net/~**briangoetz/doctmp/diff1<http://cr.openjdk.java.net/~briangoetz/doctmp/diff1>
>>>
>>>
>>>
>>>
>>> On 9/2/2013 2:42 PM, Tim Peierls wrote:
>>>
>>>> I sent Brian comments on the package summary a couple of days ago. I am
>>>> curious to see whether there's any overlap or disagreement between what
>>>> Joe wrote and what I wrote, but I'm sort of hoping Brian will summarize
>>>> all of the responses rather than having to wade through them myself.
>>>> (Yes, I know that just adds to Brian's work pile, but some sort of
>>>> summary will be needed in any case.)
>>>>
>>>> --tim
>>>>
>>>>
>>>> On Mon, Sep 2, 2013 at 12:15 PM, Joe Bowbeer <joe.bowbeer at gmail.com
>>>> <mailto:joe.bowbeer at gmail.com>**> wrote:
>>>>
>>>>     I just sent Brian comments on the package description and the
>>>>     BaseStream family of interfaces.
>>>>
>>>>     Overall, I like the way this is coming together.  The package
>>>>     description is substantial, but it's worth the programmer's time.
>>>>       The references to package-description in the Stream methods are
>>>>     effective.  Hey, I *feel* like I understand.
>>>>
>>>>     However, there's plenty of room for improvement.  I'd be happy to
>>>>     send my detailed review - or a simplified summary - to this list if
>>>>     there is interest.
>>>>
>>>>     --Joe
>>>>
>>>>
>>>>     On Wed, Aug 28, 2013 at 2:58 PM, Brian Goetz <
>>>> brian.goetz at oracle.com
>>>>     <mailto:brian.goetz at oracle.com**>> wrote:
>>>>
>>>>         Have I mentioned that reviews of the specs and package doc at:
>>>>
>>>>         http://cr.openjdk.java.net/~__**briangoetz/doctmp/doc/<http://cr.openjdk.java.net/~__briangoetz/doctmp/doc/>
>>>>         <http://cr.openjdk.java.net/~**briangoetz/doctmp/doc/<http://cr.openjdk.java.net/~briangoetz/doctmp/doc/>
>>>> >
>>>>
>>>>         would be appreciated?
>>>>
>>>>
>>>>
>>>>
>>

From mike.duigou at oracle.com  Tue Sep  3 19:46:21 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 3 Sep 2013 19:46:21 -0700
Subject: Specs
In-Reply-To: <52262C7D.8070900@oracle.com>
References: <521E7269.6010502@oracle.com>
	<CAHzJPEpEcHajHNiE5JXCo2Wfm57GxcfGTjM9s2u-m9XZo7-v2w@mail.gmail.com>
	<CA+F8eeR+0ih-YvGrOGSnkq_wPGEwvJT+=ggfMkRRcqQu6B3-ww@mail.gmail.com>
	<52262C7D.8070900@oracle.com>
Message-ID: <6C833426-B3A1-45B6-AEBA-AE4478FA5538@oracle.com>

Stream::
- The docs duplication between the stream flavours still bothers me. Can we call out the per-flavour differences in some succinct way? If there is anything subtle in the class docs between flavours I am certain most people would miss it.

- Could the description of stream pipeline be broken into a definition list of the parts? 

- Stream source isn't distinguished as a term in the pipeline description.

- "since some stream operations may return their receiver rather than a new stream object," I would move this to a separate sentence or move the "it may not be possible to detect reuse in all cases." to the previous sentence.

- link to BaseStream.close() should be just close().

- "whose source is an IO channel" IO -> I/O

-  Replace parenthetical comment "(If a stream does require closing, it can be declared as a resource in a try-with-resources statement.)" with an example.

- Method links to sequential(), parallel() and isParallel() should use simple form (without BaseStream)

- Link to "effectively stateless" to "package-summary.html#NonInterference" should be "package-summary.html#Non-Interference"

package-info::

- "Streams differ from collections in several ways:" use a definition list to highlight the key points?

- "Streams can be obtained in a number of ways" -> "Streams can be obtained from many sources". Reinforce "source"
- "Stream operations and pipelines"
   - The intial link to itself in first sentence is redundant.
   - that stream operations are described as being "divided and combined" is possibly confusing since they refer to different things--one might think that a pipeline has one intermediate and one terminal operations. Perhaps just remove the first sentence.


I can apply any of these to the source if you would prefer.

Mike

On Sep 3 2013, at 11:37 , Brian Goetz wrote:

> Plowing through all of these today...I've got just about all the directly actionable ones processed, stumbling a bit on the less actionable ones (e.g., "This section needs work.")
> 
> I've updated the docs at the temporary site.
> 
> Old docs: http://cr.openjdk.java.net/~briangoetz/doctmp/doc0
> New docs: http://cr.openjdk.java.net/~briangoetz/doctmp/doc1
> 
> And posted a "specdiff" between them at:
>  http://cr.openjdk.java.net/~briangoetz/doctmp/diff1


> 
> 
> 
> 
> On 9/2/2013 2:42 PM, Tim Peierls wrote:
>> I sent Brian comments on the package summary a couple of days ago. I am
>> curious to see whether there's any overlap or disagreement between what
>> Joe wrote and what I wrote, but I'm sort of hoping Brian will summarize
>> all of the responses rather than having to wade through them myself.
>> (Yes, I know that just adds to Brian's work pile, but some sort of
>> summary will be needed in any case.)
>> 
>> --tim
>> 
>> 
>> On Mon, Sep 2, 2013 at 12:15 PM, Joe Bowbeer <joe.bowbeer at gmail.com
>> <mailto:joe.bowbeer at gmail.com>> wrote:
>> 
>>    I just sent Brian comments on the package description and the
>>    BaseStream family of interfaces.
>> 
>>    Overall, I like the way this is coming together.  The package
>>    description is substantial, but it's worth the programmer's time.
>>      The references to package-description in the Stream methods are
>>    effective.  Hey, I *feel* like I understand.
>> 
>>    However, there's plenty of room for improvement.  I'd be happy to
>>    send my detailed review - or a simplified summary - to this list if
>>    there is interest.
>> 
>>    --Joe
>> 
>> 
>>    On Wed, Aug 28, 2013 at 2:58 PM, Brian Goetz <brian.goetz at oracle.com
>>    <mailto:brian.goetz at oracle.com>> wrote:
>> 
>>        Have I mentioned that reviews of the specs and package doc at:
>> 
>>        http://cr.openjdk.java.net/~__briangoetz/doctmp/doc/
>>        <http://cr.openjdk.java.net/~briangoetz/doctmp/doc/>
>> 
>>        would be appreciated?
>> 
>> 
>> 


From joe.bowbeer at gmail.com  Tue Sep  3 22:59:25 2013
From: joe.bowbeer at gmail.com (Joe Bowbeer)
Date: Tue, 3 Sep 2013 22:59:25 -0700
Subject: Specs
In-Reply-To: <6C833426-B3A1-45B6-AEBA-AE4478FA5538@oracle.com>
References: <521E7269.6010502@oracle.com>
	<CAHzJPEpEcHajHNiE5JXCo2Wfm57GxcfGTjM9s2u-m9XZo7-v2w@mail.gmail.com>
	<CA+F8eeR+0ih-YvGrOGSnkq_wPGEwvJT+=ggfMkRRcqQu6B3-ww@mail.gmail.com>
	<52262C7D.8070900@oracle.com>
	<6C833426-B3A1-45B6-AEBA-AE4478FA5538@oracle.com>
Message-ID: <CAHzJPEqZP4FhjrT4MrpRu+OaOqdSYKjDFK23rjMTHK9OBsRgrg@mail.gmail.com>

FWIW, I made the same point about docs duplication.

All five stream interfaces (BaseStream, DoubleStream, IntStream,
LongStream, and Stream) appear with an identical description in the class
overview:

http://cr.openjdk.java.net/~briangoetz/doctmp/doc1/

Furthermore, there is no distinction in the javadoc between the base
interface BaseStream, which is not something programmers will tend to use,
and the four subinterfaces that will be commonly used.

--Joe


On Tue, Sep 3, 2013 at 7:46 PM, Mike Duigou <mike.duigou at oracle.com> wrote:

> Stream::
> - The docs duplication between the stream flavours still bothers me. Can
> we call out the per-flavour differences in some succinct way? If there is
> anything subtle in the class docs between flavours I am certain most people
> would miss it.
>
> - Could the description of stream pipeline be broken into a definition
> list of the parts?
>
> - Stream source isn't distinguished as a term in the pipeline description.
>
> - "since some stream operations may return their receiver rather than a
> new stream object," I would move this to a separate sentence or move the
> "it may not be possible to detect reuse in all cases." to the previous
> sentence.
>
> - link to BaseStream.close() should be just close().
>
> - "whose source is an IO channel" IO -> I/O
>
> -  Replace parenthetical comment "(If a stream does require closing, it
> can be declared as a resource in a try-with-resources statement.)" with an
> example.
>
> - Method links to sequential(), parallel() and isParallel() should use
> simple form (without BaseStream)
>
> - Link to "effectively stateless" to
> "package-summary.html#NonInterference" should be
> "package-summary.html#Non-Interference"
>
> package-info::
>
> - "Streams differ from collections in several ways:" use a definition list
> to highlight the key points?
>
> - "Streams can be obtained in a number of ways" -> "Streams can be
> obtained from many sources". Reinforce "source"
> - "Stream operations and pipelines"
>    - The intial link to itself in first sentence is redundant.
>    - that stream operations are described as being "divided and combined"
> is possibly confusing since they refer to different things--one might think
> that a pipeline has one intermediate and one terminal operations. Perhaps
> just remove the first sentence.
>
>
> I can apply any of these to the source if you would prefer.
>
> Mike
>
> On Sep 3 2013, at 11:37 , Brian Goetz wrote:
>
> > Plowing through all of these today...I've got just about all the
> directly actionable ones processed, stumbling a bit on the less actionable
> ones (e.g., "This section needs work.")
> >
> > I've updated the docs at the temporary site.
> >
> > Old docs: http://cr.openjdk.java.net/~briangoetz/doctmp/doc0
> > New docs: http://cr.openjdk.java.net/~briangoetz/doctmp/doc1
> >
> > And posted a "specdiff" between them at:
> >  http://cr.openjdk.java.net/~briangoetz/doctmp/diff1
>
>
> >
> >
> >
> >
> > On 9/2/2013 2:42 PM, Tim Peierls wrote:
> >> I sent Brian comments on the package summary a couple of days ago. I am
> >> curious to see whether there's any overlap or disagreement between what
> >> Joe wrote and what I wrote, but I'm sort of hoping Brian will summarize
> >> all of the responses rather than having to wade through them myself.
> >> (Yes, I know that just adds to Brian's work pile, but some sort of
> >> summary will be needed in any case.)
> >>
> >> --tim
> >>
> >>
> >> On Mon, Sep 2, 2013 at 12:15 PM, Joe Bowbeer <joe.bowbeer at gmail.com
> >> <mailto:joe.bowbeer at gmail.com>> wrote:
> >>
> >>    I just sent Brian comments on the package description and the
> >>    BaseStream family of interfaces.
> >>
> >>    Overall, I like the way this is coming together.  The package
> >>    description is substantial, but it's worth the programmer's time.
> >>      The references to package-description in the Stream methods are
> >>    effective.  Hey, I *feel* like I understand.
> >>
> >>    However, there's plenty of room for improvement.  I'd be happy to
> >>    send my detailed review - or a simplified summary - to this list if
> >>    there is interest.
> >>
> >>    --Joe
> >>
> >>
> >>    On Wed, Aug 28, 2013 at 2:58 PM, Brian Goetz <brian.goetz at oracle.com
> >>    <mailto:brian.goetz at oracle.com>> wrote:
> >>
> >>        Have I mentioned that reviews of the specs and package doc at:
> >>
> >>        http://cr.openjdk.java.net/~__briangoetz/doctmp/doc/
> >>        <http://cr.openjdk.java.net/~briangoetz/doctmp/doc/>
> >>
> >>        would be appreciated?
> >>
> >>
> >>
>
>

From dl at cs.oswego.edu  Wed Sep  4 04:05:01 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 04 Sep 2013 07:05:01 -0400
Subject: Specs
In-Reply-To: <52262FE8.4040304@oracle.com>
References: <521E7269.6010502@oracle.com>
	<CAHzJPEpEcHajHNiE5JXCo2Wfm57GxcfGTjM9s2u-m9XZo7-v2w@mail.gmail.com>
	<CA+F8eeR+0ih-YvGrOGSnkq_wPGEwvJT+=ggfMkRRcqQu6B3-ww@mail.gmail.com>
	<52262C7D.8070900@oracle.com>
	<FA7A6351-3496-48B8-A9C1-F7570A6380AE@gmail.com>
	<52262FE8.4040304@oracle.com>
Message-ID: <522713DD.3030004@cs.oswego.edu>

On 09/03/2013 02:52 PM, Brian Goetz wrote:
> Agreed.  We need to do more to seed the user's mental cost model, so they can
> reason about what is likely to be faster or slower.
>
> So, what should we be saying, and where should it be said?  Clearly we can talk
> some in the "Parallelism" section.  Also, I think we should have some @implNote
> for some of the problematic operations, such as limit, where we describe the
> cases that work really well (e.g., parallel limit works great on SUBSIZED
> sources) or not so well (groupingBy with HashMap sucks in parallel, due to
> expensive merge.)
>
> On 9/3/2013 2:50 PM, Sam Pullara wrote:
>> I still don't think there is sufficient explanation of the motivations around
>> why someone would use parallel() and what the performance implications of
>> using it might be.

I agree that people need some advice on the fine points of using
parallel to avoid unexpected slowdowns, but Javadocs are not
an ideal place to describe possibly-transient facts about
crummy performance in various cases. (They belong in the bug database! :-)

I think the only kinds of implicit advice suitable for Javadocs
are based on good examples of good usages.

-Doug




From brian.goetz at oracle.com  Wed Sep  4 08:00:35 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 04 Sep 2013 11:00:35 -0400
Subject: Specs
In-Reply-To: <522713DD.3030004@cs.oswego.edu>
References: <521E7269.6010502@oracle.com>
	<CAHzJPEpEcHajHNiE5JXCo2Wfm57GxcfGTjM9s2u-m9XZo7-v2w@mail.gmail.com>
	<CA+F8eeR+0ih-YvGrOGSnkq_wPGEwvJT+=ggfMkRRcqQu6B3-ww@mail.gmail.com>
	<52262C7D.8070900@oracle.com>
	<FA7A6351-3496-48B8-A9C1-F7570A6380AE@gmail.com>
	<52262FE8.4040304@oracle.com> <522713DD.3030004@cs.oswego.edu>
Message-ID: <52274B13.2000403@oracle.com>

> I agree that people need some advice on the fine points of using
> parallel to avoid unexpected slowdowns, but Javadocs are not
> an ideal place to describe possibly-transient facts about
> crummy performance in various cases. (They belong in the bug database! :-)

I think @implNote is a fine place to put possibly-transient details that 
users might use at their own risk?  Especially if we can frame it as 
"things that work" rather than "things that don't."  For example, in 
limit, we could @implNote: parallel operations on ordered streams may 
require O(limit) buffering.  But if the stream is SIZED and SUBSIZED, 
don't worry, be happy.

The idea here is: you warn users of possible things to watch out for, 
and identify conditions under which they are safe.  Ideally that set of 
conditions would grow over time, making it less likely such transient 
information gets stale.


From forax at univ-mlv.fr  Sun Sep  8 09:18:26 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 08 Sep 2013 18:18:26 +0200
Subject: No 'fold left' without a combiner ?
In-Reply-To: <522B7539.30501@oracle.com>
References: <51E40C99.30406@univ-mlv.fr>
	<CACzrW9BP7_Gaxjt=Fi2cYf8NtPNSSa4eyLLEMivWveX2qh-voQ@mail.gmail.com>
	<CAL2Kp+jvqTGu7UOG=0tWPELmB9Li4i6hfsF3ST0hc88RL7qxGg@mail.gmail.com>
	<CACuKZqF2L4_RHQNL0HL0_DfySZgsohFgA3nbqnMAoBB9V5ceJA@mail.gmail.com>
	<9FC2B838-26C5-47DB-A24F-2EE6F8520F56@oracle.com>
	<CACuKZqGvoL10JTuXyYWL4mgOzZy9QShfiD7rweZqZsEcxfAeiw@mail.gmail.com>
	<522A58FF.8080401@oracle.com> <522AEC19.7050801@univ-mlv.fr>
	<522B36AF.6070707@oracle.com> <522B4DE4.90805@univ-mlv.fr>
	<522B5EC3.9010105@oracle.com> <522B724B.3030703@univ-mlv.fr>
	<522B7539.30501@oracle.com>
Message-ID: <522CA352.60501@univ-mlv.fr>

Did I say that I will send you an email to the EG lists each time I will 
be annoyed by visibility of lambda parameter rule ?

ArrayList<Advice> advices = ...
AnnotatedElement annotatedElement = ...
MethodHandle mh = advices.stream().reduce(impl, (mh, advice) -> 
advice.chain(annotatedElement, mh), null);

In fact, there is another issue, (the real reason of this email), this 
code throws a NPE at runtime because I use null as combiner.
It seems there is no way to express a left fold on values (different 
from T) when the values can not be combined.

I've fixed the issue by writing,
   MethodHandle target = advices.stream().reduce(impl,
       (mh, advice) -> advice.chain(annotatedElement, mh),
       (_1, _2) -> { throw new AssertionError(); } );
but it's clearly ugly.

cheers,
R?mi


From paul.sandoz at oracle.com  Mon Sep  9 06:48:00 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 9 Sep 2013 15:48:00 +0200
Subject: No 'fold left' without a combiner ?
In-Reply-To: <522CA352.60501@univ-mlv.fr>
References: <51E40C99.30406@univ-mlv.fr>
	<CACzrW9BP7_Gaxjt=Fi2cYf8NtPNSSa4eyLLEMivWveX2qh-voQ@mail.gmail.com>
	<CAL2Kp+jvqTGu7UOG=0tWPELmB9Li4i6hfsF3ST0hc88RL7qxGg@mail.gmail.com>
	<CACuKZqF2L4_RHQNL0HL0_DfySZgsohFgA3nbqnMAoBB9V5ceJA@mail.gmail.com>
	<9FC2B838-26C5-47DB-A24F-2EE6F8520F56@oracle.com>
	<CACuKZqGvoL10JTuXyYWL4mgOzZy9QShfiD7rweZqZsEcxfAeiw@mail.gmail.com>
	<522A58FF.8080401@oracle.com> <522AEC19.7050801@univ-mlv.fr>
	<522B36AF.6070707@oracle.com> <522B4DE4.90805@univ-mlv.fr>
	<522B5EC3.9010105@oracle.com> <522B724B.3030703@univ-mlv.fr>
	<522B7539.30501@oracle.com> <522CA352.60501@univ-mlv.fr>
Message-ID: <D68E49CE-8805-4A57-AAF5-1C90F3C59830@oracle.com>


On Sep 8, 2013, at 6:18 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> Did I say that I will send you an email to the EG lists each time I will be annoyed by visibility of lambda parameter rule ?
> 
> ArrayList<Advice> advices = ...
> AnnotatedElement annotatedElement = ...
> MethodHandle mh = advices.stream().reduce(impl, (mh, advice) -> advice.chain(annotatedElement, mh), null);
> 
> In fact, there is another issue, (the real reason of this email), this code throws a NPE at runtime because I use null as combiner.
> It seems there is no way to express a left fold on values (different from T) when the values can not be combined.
> 
> I've fixed the issue by writing,
>  MethodHandle target = advices.stream().reduce(impl,
>      (mh, advice) -> advice.chain(annotatedElement, mh),
>      (_1, _2) -> { throw new AssertionError(); } );
> but it's clearly ugly.
> 

Yes, and it will barf for parallel streams.

You might be better off using an explicit forEach or writing a static foldLeft utility method that internally calls sequential().

Paul.

From forax at univ-mlv.fr  Mon Sep  9 08:16:12 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 09 Sep 2013 17:16:12 +0200
Subject: No 'fold left' without a combiner ?
In-Reply-To: <D68E49CE-8805-4A57-AAF5-1C90F3C59830@oracle.com>
References: <51E40C99.30406@univ-mlv.fr>
	<CACzrW9BP7_Gaxjt=Fi2cYf8NtPNSSa4eyLLEMivWveX2qh-voQ@mail.gmail.com>
	<CAL2Kp+jvqTGu7UOG=0tWPELmB9Li4i6hfsF3ST0hc88RL7qxGg@mail.gmail.com>
	<CACuKZqF2L4_RHQNL0HL0_DfySZgsohFgA3nbqnMAoBB9V5ceJA@mail.gmail.com>
	<9FC2B838-26C5-47DB-A24F-2EE6F8520F56@oracle.com>
	<CACuKZqGvoL10JTuXyYWL4mgOzZy9QShfiD7rweZqZsEcxfAeiw@mail.gmail.com>
	<522A58FF.8080401@oracle.com> <522AEC19.7050801@univ-mlv.fr>
	<522B36AF.6070707@oracle.com> <522B4DE4.90805@univ-mlv.fr>
	<522B5EC3.9010105@oracle.com> <522B724B.3030703@univ-mlv.fr>
	<522B7539.30501@oracle.com> <522CA352.60501@univ-mlv.fr>
	<D68E49CE-8805-4A57-AAF5-1C90F3C59830@oracle.com>
Message-ID: <522DE63C.5060005@univ-mlv.fr>

On 09/09/2013 03:48 PM, Paul Sandoz wrote:
> On Sep 8, 2013, at 6:18 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> Did I say that I will send you an email to the EG lists each time I will be annoyed by visibility of lambda parameter rule ?
>>
>> ArrayList<Advice> advices = ...
>> AnnotatedElement annotatedElement = ...
>> MethodHandle mh = advices.stream().reduce(impl, (mh, advice) -> advice.chain(annotatedElement, mh), null);
>>
>> In fact, there is another issue, (the real reason of this email), this code throws a NPE at runtime because I use null as combiner.
>> It seems there is no way to express a left fold on values (different from T) when the values can not be combined.
>>
>> I've fixed the issue by writing,
>>   MethodHandle target = advices.stream().reduce(impl,
>>       (mh, advice) -> advice.chain(annotatedElement, mh),
>>       (_1, _2) -> { throw new AssertionError(); } );
>> but it's clearly ugly.
>>
> Yes, and it will barf for parallel streams.

yes, here I control th stream creation so no big deal
>
> You might be better off using an explicit forEach or writing a static foldLeft utility method that internally calls sequential().

or better, have a foldLeft (or whatever it's name) on Stream that throws 
an IllegalStateException if the stream is parallel.

>
> Paul.

R?mi


From brian.goetz at oracle.com  Mon Sep  9 08:32:51 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 09 Sep 2013 11:32:51 -0400
Subject: No 'fold left' without a combiner ?
In-Reply-To: <522DE63C.5060005@univ-mlv.fr>
References: <51E40C99.30406@univ-mlv.fr>
	<CACzrW9BP7_Gaxjt=Fi2cYf8NtPNSSa4eyLLEMivWveX2qh-voQ@mail.gmail.com>
	<CAL2Kp+jvqTGu7UOG=0tWPELmB9Li4i6hfsF3ST0hc88RL7qxGg@mail.gmail.com>
	<CACuKZqF2L4_RHQNL0HL0_DfySZgsohFgA3nbqnMAoBB9V5ceJA@mail.gmail.com>
	<9FC2B838-26C5-47DB-A24F-2EE6F8520F56@oracle.com>
	<CACuKZqGvoL10JTuXyYWL4mgOzZy9QShfiD7rweZqZsEcxfAeiw@mail.gmail.com>
	<522A58FF.8080401@oracle.com> <522AEC19.7050801@univ-mlv.fr>
	<522B36AF.6070707@oracle.com> <522B4DE4.90805@univ-mlv.fr>
	<522B5EC3.9010105@oracle.com> <522B724B.3030703@univ-mlv.fr>
	<522B7539.30501@oracle.com> <522CA352.60501@univ-mlv.fr>
	<D68E49CE-8805-4A57-AAF5-1C90F3C59830@oracle.com>
	<522DE63C.5060005@univ-mlv.fr>
Message-ID: <522DEA23.9060107@oracle.com>

> or better, have a foldLeft (or whatever it's name) on Stream that throws
> an IllegalStateException if the stream is parallel.

No, that's not better :)

The pervasive sequential-think that most developers bring to the table 
in 2013 is not anyone's friend.  We've gone to great effort to design an 
API where, if properly used, works correctly regardless of whether the 
pipeline executes sequentially or in parallel.  The result is a cleaner 
and simpler API, and one that better prepares developers for computing 
in the coming decade.

Adding a handful of sequential-only operations may make certain use 
cases easier, but there's a hidden cost -- reasoning about stream 
pipelines becomes harder for everyone, because now parallel 
compatibility becomes an element of the model which must be considered. 
  Short-term gain, long-term pain.  No thank you!

Please deposit your sequential glasses in the bin by the door.  You 
won't be needing them any more.


From daniel.smith at oracle.com  Tue Sep 10 15:07:52 2013
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 10 Sep 2013 16:07:52 -0600
Subject: Interesting inference case
In-Reply-To: <50000D4B-27C5-4878-BDB5-88434FE18A32@gmail.com>
References: <50000D4B-27C5-4878-BDB5-88434FE18A32@gmail.com>
Message-ID: <7FAF0F2A-FE67-4641-894F-3BBB58FCA799@oracle.com>

See the "Overload resolution simplification" thread.

this::call is an inexact method reference when 'call' is overloaded, and exact otherwise.

Inexact method references are ignored (we don't try to resolve them, or figure out their return type, etc.) until the outer overload resolution is done.  Hence, there's no basis for choosing one variant of 'submit' over another.

Exact method references can influence overload resolution.  In this case, because 'call' returns 'void', we know that the method reference cannot be a Callable, and so that candidate is discarded.

?Dan

On Sep 2, 2013, at 11:19 AM, Sam Pullara <spullara at gmail.com> wrote:

> I was trying to pass Semaphore::release to ExecutorService.submit and ran into a puzzling compile error. Here is a reproduction case:
> 
> public class InferTest {
>    void call() {}
> //    void call(int i) {}
> 
>    @Test
>    public void test() {
>        ExecutorService es = Executors.newCachedThreadPool();
>        es.submit(this::call);
>    }
> }
> 
> With the comment, this compiles fine. If you uncomment the second call() method it fails with:
> 
> java: reference to submit is ambiguous
>  both method <T>submit(java.util.concurrent.Callable<T>) in java.util.concurrent.ExecutorService and method submit(java.lang.Runnable) in java.util.concurrent.ExecutorService match
> java: incompatible types: cannot infer type-variable(s) T
>    (argument mismatch; bad return type in method reference
>      void cannot be converted to T)
> 
> I'm not sure why the overload on call() would cause the ambiguity. 
> 
> Sam
> 


From forax at univ-mlv.fr  Tue Sep 10 08:42:23 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 10 Sep 2013 17:42:23 +0200
Subject: No 'fold left' without a combiner ?
In-Reply-To: <522DEA23.9060107@oracle.com>
References: <51E40C99.30406@univ-mlv.fr>
	<CACzrW9BP7_Gaxjt=Fi2cYf8NtPNSSa4eyLLEMivWveX2qh-voQ@mail.gmail.com>
	<CAL2Kp+jvqTGu7UOG=0tWPELmB9Li4i6hfsF3ST0hc88RL7qxGg@mail.gmail.com>
	<CACuKZqF2L4_RHQNL0HL0_DfySZgsohFgA3nbqnMAoBB9V5ceJA@mail.gmail.com>
	<9FC2B838-26C5-47DB-A24F-2EE6F8520F56@oracle.com>
	<CACuKZqGvoL10JTuXyYWL4mgOzZy9QShfiD7rweZqZsEcxfAeiw@mail.gmail.com>
	<522A58FF.8080401@oracle.com> <522AEC19.7050801@univ-mlv.fr>
	<522B36AF.6070707@oracle.com> <522B4DE4.90805@univ-mlv.fr>
	<522B5EC3.9010105@oracle.com> <522B724B.3030703@univ-mlv.fr>
	<522B7539.30501@oracle.com> <522CA352.60501@univ-mlv.fr>
	<D68E49CE-8805-4A57-AAF5-1C90F3C59830@oracle.com>
	<522DE63C.5060005@univ-mlv.fr> <522DEA23.9060107@oracle.com>
Message-ID: <522F3DDF.7020702@univ-mlv.fr>

On 09/09/2013 05:32 PM, Brian Goetz wrote:
>> or better, have a foldLeft (or whatever it's name) on Stream that throws
>> an IllegalStateException if the stream is parallel.
>
> No, that's not better :)
>
> The pervasive sequential-think that most developers bring to the table 
> in 2013 is not anyone's friend.  We've gone to great effort to design 
> an API where, if properly used, works correctly regardless of whether 
> the pipeline executes sequentially or in parallel.  The result is a 
> cleaner and simpler API, and one that better prepares developers for 
> computing in the coming decade.
>
> Adding a handful of sequential-only operations may make certain use 
> cases easier, but there's a hidden cost -- reasoning about stream 
> pipelines becomes harder for everyone, because now parallel 
> compatibility becomes an element of the model which must be 
> considered.  Short-term gain, long-term pain.  No thank you!

so for my example, the idea is to *not* use a stream and use a for loop 
instead, right ?

>
> Please deposit your sequential glasses in the bin by the door. You 
> won't be needing them any more.
>

:)

R?mi


From brian.goetz at oracle.com  Tue Sep 10 18:53:15 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 10 Sep 2013 21:53:15 -0400
Subject: No 'fold left' without a combiner ?
In-Reply-To: <522F3DDF.7020702@univ-mlv.fr>
References: <51E40C99.30406@univ-mlv.fr>
	<CACzrW9BP7_Gaxjt=Fi2cYf8NtPNSSa4eyLLEMivWveX2qh-voQ@mail.gmail.com>
	<CAL2Kp+jvqTGu7UOG=0tWPELmB9Li4i6hfsF3ST0hc88RL7qxGg@mail.gmail.com>
	<CACuKZqF2L4_RHQNL0HL0_DfySZgsohFgA3nbqnMAoBB9V5ceJA@mail.gmail.com>
	<9FC2B838-26C5-47DB-A24F-2EE6F8520F56@oracle.com>
	<CACuKZqGvoL10JTuXyYWL4mgOzZy9QShfiD7rweZqZsEcxfAeiw@mail.gmail.com>
	<522A58FF.8080401@oracle.com> <522AEC19.7050801@univ-mlv.fr>
	<522B36AF.6070707@oracle.com> <522B4DE4.90805@univ-mlv.fr>
	<522B5EC3.9010105@oracle.com> <522B724B.3030703@univ-mlv.fr>
	<522B7539.30501@oracle.com> <522CA352.60501@univ-mlv.fr>
	<D68E49CE-8805-4A57-AAF5-1C90F3C59830@oracle.com>
	<522DE63C.5060005@univ-mlv.fr> <522DEA23.9060107@oracle.com>
	<522F3DDF.7020702@univ-mlv.fr>
Message-ID: <522FCD0B.90706@oracle.com>

>> Adding a handful of sequential-only operations may make certain use
>> cases easier, but there's a hidden cost -- reasoning about stream
>> pipelines becomes harder for everyone, because now parallel
>> compatibility becomes an element of the model which must be
>> considered.  Short-term gain, long-term pain.  No thank you!
>
> so for my example, the idea is to *not* use a stream and use a for loop
> instead, right ?

The idea is to do what feels like natural code.  We've not outlawed the 
for-loop.  There will be places, obviously only in sequential cases, 
where for-loops are simpler, easier, faster, or more natural.  Whether 
to use a loop or a stream pipeline depends on how much else the stream 
is doing.

For example,

   list.stream().reduce(...)

could just as easily be a for-loop, and at that point, its a 
pick-your-poison thing at this point (the imperative for loop or the 
streamy reduce that makes you specify an extra argument.)  But if you 
were doing

   list.stream()
       .map(...)
       .filter(...)
       .distinct()
       .reduce(...)

going back to a loop would be giving up a lot.


From forax at univ-mlv.fr  Sat Sep 14 08:33:11 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 14 Sep 2013 17:33:11 +0200
Subject: Puzzler: Stream.of(null)
Message-ID: <523481B7.2060704@univ-mlv.fr>

What this line does ?
   Stream.of(null).forEach(System.out::println);

EnumSet solve that issue by declaring of() like this of(T, T...).

cheers,
R?mi




From brian.goetz at oracle.com  Sat Sep 14 08:37:01 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 14 Sep 2013 11:37:01 -0400
Subject: Puzzler: Stream.of(null)
In-Reply-To: <523481B7.2060704@univ-mlv.fr>
References: <523481B7.2060704@univ-mlv.fr>
Message-ID: <5234829D.5030106@oracle.com>

Heh, cute.

On 9/14/2013 11:33 AM, Remi Forax wrote:
> What this line does ?
>    Stream.of(null).forEach(System.out::println);
>
> EnumSet solve that issue by declaring of() like this of(T, T...).
>
> cheers,
> R?mi
>
>
>

From Donald.Raab at gs.com  Sun Sep 15 12:43:54 2013
From: Donald.Raab at gs.com (Raab, Donald)
Date: Sun, 15 Sep 2013 15:43:54 -0400
Subject: Thank you!
Message-ID: <6712820CB52CFB4D842561213A77C0540528467971@GSCMAMP09EX.firmwide.corp.gs.com>

Thank you everyone for the signed thermos from JVMLS.  This was an extremely nice and unexpected surprise and is very much appreciated.  Apologies I couldn't make it to the summit this year.  Hopefully I'll be able to make it next year and thank everyone again in person.

Cheers,
Don


From brian.goetz at oracle.com  Mon Sep 16 13:40:51 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 16 Sep 2013 16:40:51 -0400
Subject: Spec update for Streams
Message-ID: <52376CD3.8090909@oracle.com>

Below are some spec updates to Stream.sort, Stream.distinct, and 
Stream.collect which capture some guarantees about ordering that we 
discussed but which were never incorporated into the spec.  Notably:

  - Sorting is stable iff the stream is ordered
  - Duplicate removal is stable iff the stream is ordered (i.e., if 
there are duplicates, a stable implementation would preserve the first one)
  - If a stream is parallel and a Collector is concurrent and either the 
stream or the collector is unordered, then a concurrent reduction is 
performed by stream.collect(Collector).

Corresponding spec follows, please review.


diff --git a/src/share/classes/java/util/stream/Stream.java 
b/src/share/classes/java/util/stream/Stream.java
--- a/src/share/classes/java/util/stream/Stream.java
+++ b/src/share/classes/java/util/stream/Stream.java
@@ -293,6 +293,11 @@
       * Returns a stream consisting of the distinct elements (according to
       * {@link Object#equals(Object)}) of this stream.
       *
+     * <p>For ordered streams, the selection of distinct elements is stable
+     * (for duplicated elements, the element appearing first in the 
encounter
+     * order is preserved.)  For unordered streams, no stability guarantees
+     * are made.
+     *
       * <p>This is a <a href="package-summary.html#StreamOps">stateful
       * intermediate operation</a>.
       *
@@ -306,6 +311,9 @@
       * {@code Comparable}, a {@code java.lang.ClassCastException} may 
be thrown
       * when the terminal operation is executed.
       *
+     * <p>For ordered streams, the sort is stable.  For unordered 
streams, no
+     * stability guarantees are made.
+     *
       * <p>This is a <a href="package-summary.html#StreamOps">stateful
       * intermediate operation</a>.
       *
@@ -317,6 +325,9 @@
       * Returns a stream consisting of the elements of this stream, sorted
       * according to the provided {@code Comparator}.
       *
+     * <p>For ordered streams, the sort is stable.  For unordered 
streams, no
+     * stability guarantees are made.
+     *
       * <p>This is a <a href="package-summary.html#StreamOps">stateful
       * intermediate operation</a>.
       *
@@ -678,6 +689,13 @@
       * collection strategies and composition of collect operations such as
       * multiple-level grouping or partitioning.
       *
+     * <p>If the stream is parallel, and the {@code Collector}
+     * is {@link Collector.Characteristics.CONCURRENT concurrent}, and
+     * either the stream is unordered or the collector is
+     * {@link Collector.Characteristics.UNORDERED unordered},
+     * then a concurrent reduction will be performed (see {@link 
Collector} for
+     * details on concurrent reduction.)
+     *
       * <p>This is a <a href="package-summary.html#StreamOps">terminal
       * operation</a>.
       *

From Donald.Raab at gs.com  Sat Sep 21 11:09:32 2013
From: Donald.Raab at gs.com (Raab, Donald)
Date: Sat, 21 Sep 2013 14:09:32 -0400
Subject: GS Collections 4.0 Released
Message-ID: <6712820CB52CFB4D842561213A77C054052A2BBD98@GSCMAMP09EX.firmwide.corp.gs.com>

I thought I would update this group quickly on our latest release of GS Collections.  Release notes are here:

https://github.com/goldmansachs/gs-collections/releases

We now have full support for all primitive types including mutable, immutable, unmodifiable, synchronized and lazy across primitive lists, sets, maps, bags and stacks.  We've also added a new feature to our primitive sets called "freeze".  We may add this feature in the future to our other primitive and object containers if developers request it.  You can transform from an object collection to any primitive type either eagerly or lazily, and back again.  We do not support primitive to primitive type conversions yet, but may add those in a future release if folks have a need for them.

I've updated our Java 8 kata solutions to leverage the latest features in GSC 4.0.  We've also discovered a neat way to parameterize a method reference using our optimized (but lesser known) "With" methods (e.g. selectWith, collectWith, anySatisfyWith, etc.).  You can see two examples of this in the kata solutions.  Method references are such a cool feature, our tendency is to want to use them as much as possible.  Being able to parameterize a method reference gives us even more leverage of this wonderful Java 8 feature.  Kudos and thanks to Oracle and the Java 8 Lambda developers on building this most excellent feature.

https://github.com/goldmansachs/gs-collections-kata/tree/solutions-java8

Parameterized method reference examples linked below.  Look for selectWith example in the getLondonCustomers() test and the detectWith example in whoSuppliesSandwichToaster() test.

https://github.com/goldmansachs/gs-collections-kata/blob/solutions-java8/src/test/java/com/gs/collections/kata/Exercise1Test.java
https://github.com/goldmansachs/gs-collections-kata/blob/solutions-java8/src/test/java/com/gs/collections/kata/Exercise5Test.java

We've added two new tests to our kata as well that leverage our new aggregateBy api on RichIterable.  The new tests are totalOrderValuesByCity() and totalOrderValuesByItem().

https://github.com/goldmansachs/gs-collections-kata/blob/solutions-java8/src/test/java/com/gs/collections/kata/Exercise9Test.java

I am in the process of porting the aggregation tests to use Java 8 Streams on the JCF solutions branch.  I should hopefully have that done and pushed to GitHub this week.

Cheers,
Don


From forax at univ-mlv.fr  Sun Sep 22 10:43:54 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 22 Sep 2013 19:43:54 +0200
Subject: Variation of DoubleStream.flatMap ?
Message-ID: <523F2C5A.4020102@univ-mlv.fr>

I wonder why there is only one variation of flatMap on DoubleStream (and 
other primitive stream).

R?mi


From brian.goetz at oracle.com  Sun Sep 22 14:46:04 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 22 Sep 2013 16:46:04 -0500
Subject: Variation of DoubleStream.flatMap ?
In-Reply-To: <523F2C5A.4020102@univ-mlv.fr>
References: <523F2C5A.4020102@univ-mlv.fr>
Message-ID: <A3EF739F-B679-44EB-B778-F0F2660BEEFD@oracle.com>

So, it seemed the Object -> int versions were going to be far more common than the int -> Object versions (can you think of a lot of examples?) and, if you need, you can always go intStream.boxed().flatMap().  

On Sep 22, 2013, at 12:43 PM, Remi Forax wrote:

> I wonder why there is only one variation of flatMap on DoubleStream (and other primitive stream).
> 
> R?mi
> 


From forax at univ-mlv.fr  Sun Sep 22 14:53:58 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 22 Sep 2013 23:53:58 +0200
Subject: Variation of DoubleStream.flatMap ?
In-Reply-To: <A3EF739F-B679-44EB-B778-F0F2660BEEFD@oracle.com>
References: <523F2C5A.4020102@univ-mlv.fr>
	<A3EF739F-B679-44EB-B778-F0F2660BEEFD@oracle.com>
Message-ID: <523F66F6.4020507@univ-mlv.fr>

On 09/22/2013 11:46 PM, Brian Goetz wrote:
> So, it seemed the Object -> int versions were going to be far more common than the int -> Object versions (can you think of a lot of examples?) and, if you need, you can always go intStream.boxed().flatMap().

I need double -> stream of int, exactly, I need this lambda
   value -> IntStream.of((int)value, ((int)(value*10))%10)

R?mi

>
> On Sep 22, 2013, at 12:43 PM, Remi Forax wrote:
>
>> I wonder why there is only one variation of flatMap on DoubleStream (and other primitive stream).
>>
>> R?mi
>>


From brian.goetz at oracle.com  Sun Sep 22 15:00:07 2013
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 22 Sep 2013 17:00:07 -0500
Subject: Variation of DoubleStream.flatMap ?
In-Reply-To: <523F66F6.4020507@univ-mlv.fr>
References: <523F2C5A.4020102@univ-mlv.fr>
	<A3EF739F-B679-44EB-B778-F0F2660BEEFD@oracle.com>
	<523F66F6.4020507@univ-mlv.fr>
Message-ID: <15961BDF-4108-4F4D-9DFC-B6B11B07CF8E@oracle.com>

So:
  doubleStream.flatMap(...).mapToInt(i -> i)...

On Sep 22, 2013, at 4:53 PM, Remi Forax wrote:

> On 09/22/2013 11:46 PM, Brian Goetz wrote:
>> So, it seemed the Object -> int versions were going to be far more common than the int -> Object versions (can you think of a lot of examples?) and, if you need, you can always go intStream.boxed().flatMap().
> 
> I need double -> stream of int, exactly, I need this lambda
>  value -> IntStream.of((int)value, ((int)(value*10))%10)
> 
> R?mi
> 
>> 
>> On Sep 22, 2013, at 12:43 PM, Remi Forax wrote:
>> 
>>> I wonder why there is only one variation of flatMap on DoubleStream (and other primitive stream).
>>> 
>>> R?mi
>>> 
> 


From forax at univ-mlv.fr  Sun Sep 22 15:06:33 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 23 Sep 2013 00:06:33 +0200
Subject: Variation of DoubleStream.flatMap ?
In-Reply-To: <15961BDF-4108-4F4D-9DFC-B6B11B07CF8E@oracle.com>
References: <523F2C5A.4020102@univ-mlv.fr>
	<A3EF739F-B679-44EB-B778-F0F2660BEEFD@oracle.com>
	<523F66F6.4020507@univ-mlv.fr>
	<15961BDF-4108-4F4D-9DFC-B6B11B07CF8E@oracle.com>
Message-ID: <523F69E9.1000309@univ-mlv.fr>

On 09/23/2013 12:00 AM, Brian Goetz wrote:
> So:
>    doubleStream.flatMap(...).mapToInt(i -> i)...

don't work because % is not applied on both value.

R?mi

>
> On Sep 22, 2013, at 4:53 PM, Remi Forax wrote:
>
>> On 09/22/2013 11:46 PM, Brian Goetz wrote:
>>> So, it seemed the Object -> int versions were going to be far more common than the int -> Object versions (can you think of a lot of examples?) and, if you need, you can always go intStream.boxed().flatMap().
>> I need double -> stream of int, exactly, I need this lambda
>>   value -> IntStream.of((int)value, ((int)(value*10))%10)
>>
>> R?mi
>>
>>> On Sep 22, 2013, at 12:43 PM, Remi Forax wrote:
>>>
>>>> I wonder why there is only one variation of flatMap on DoubleStream (and other primitive stream).
>>>>
>>>> R?mi
>>>>


From Donald.Raab at gs.com  Mon Sep 23 11:56:34 2013
From: Donald.Raab at gs.com (Raab, Donald)
Date: Mon, 23 Sep 2013 14:56:34 -0400
Subject: GS Collections 4.0 Released
In-Reply-To: <6712820CB52CFB4D842561213A77C054052A28CC16@GSCMAMP09EX.firmwide.corp.gs.com>
References: <6712820CB52CFB4D842561213A77C054052A28CC16@GSCMAMP09EX.firmwide.corp.gs.com>
Message-ID: <6712820CB52CFB4D842561213A77C054052B7F1710@GSCMAMP09EX.firmwide.corp.gs.com>

The JCF branch of the kata has been updated.  You will see two examples using groupingBy and summingDouble now.

https://github.com/goldmansachs/gs-collections-kata/blob/solutions-java8-jcf/src/test/java/com/gs/collections/kata/Exercise9Test.java

Thanks,
Don

_____________________________________________
From: Raab, Donald [Tech]
Sent: Saturday, September 21, 2013 2:10 PM
To: lambda-libs-spec-experts at openjdk.java.net
Cc: Motlin, Craig P. [Tech]; Hindupur, Bhavana [Tech]; Zakharov, Vladimir [Tech]
Subject: GS Collections 4.0 Released


I thought I would update this group quickly on our latest release of GS Collections.  Release notes are here:

https://github.com/goldmansachs/gs-collections/releases

We now have full support for all primitive types including mutable, immutable, unmodifiable, synchronized and lazy across primitive lists, sets, maps, bags and stacks.  We've also added a new feature to our primitive sets called "freeze".  We may add this feature in the future to our other primitive and object containers if developers request it.  You can transform from an object collection to any primitive type either eagerly or lazily, and back again.  We do not support primitive to primitive type conversions yet, but may add those in a future release if folks have a need for them.

I've updated our Java 8 kata solutions to leverage the latest features in GSC 4.0.  We've also discovered a neat way to parameterize a method reference using our optimized (but lesser known) "With" methods (e.g. selectWith, collectWith, anySatisfyWith, etc.).  You can see two examples of this in the kata solutions.  Method references are such a cool feature, our tendency is to want to use them as much as possible.  Being able to parameterize a method reference gives us even more leverage of this wonderful Java 8 feature.  Kudos and thanks to Oracle and the Java 8 Lambda developers on building this most excellent feature.

https://github.com/goldmansachs/gs-collections-kata/tree/solutions-java8

Parameterized method reference examples linked below.  Look for selectWith example in the getLondonCustomers() test and the detectWith example in whoSuppliesSandwichToaster() test.

https://github.com/goldmansachs/gs-collections-kata/blob/solutions-java8/src/test/java/com/gs/collections/kata/Exercise1Test.java
https://github.com/goldmansachs/gs-collections-kata/blob/solutions-java8/src/test/java/com/gs/collections/kata/Exercise5Test.java

We've added two new tests to our kata as well that leverage our new aggregateBy api on RichIterable.  The new tests are totalOrderValuesByCity() and totalOrderValuesByItem().

https://github.com/goldmansachs/gs-collections-kata/blob/solutions-java8/src/test/java/com/gs/collections/kata/Exercise9Test.java

I am in the process of porting the aggregation tests to use Java 8 Streams on the JCF solutions branch.  I should hopefully have that done and pushed to GitHub this week.

Cheers,
Don


From mike.duigou at oracle.com  Thu Sep 26 13:34:49 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 26 Sep 2013 13:34:49 -0700
Subject: Another round of libraries spec review
Message-ID: <ACF4931B-D0EF-4808-AF41-B6980F4994E6@oracle.com>

Hello all;

The changes from Brian's last round of spec updates have now made their way into JDK 8 preview build b108. (http://download.java.net/jdk8/docs/api/java/util/stream/package-summary.html) I am collecting additional spec updates, fixes and changes for another round before we begin the final EG review. This will include combing through the feedback in the last round to see if anything got missed. If you have additional feedback, want to make additional comments or corrections then now is a very good time for EG members to review the specs. I will try to have a set of changes proposed for integration to the JDK mainline repos by next Friday. 

Thanks,

Mike