Re: We need to add blocking methods to CompletionStage!

2016-09-27 Thread Viktor Klang
On Sep 27, 2016 01:18, "Martin Buchholz" wrote: > > > > On Mon, Sep 26, 2016 at 7:55 AM, Viktor Klang wrote: >>> >>> >>> >>> Test methods, >> >> >> Yeah, I thought so as well, but it turns out that when you have tons of async tests, not being able to

Re: We need to add blocking methods to CompletionStage!

2016-09-26 Thread Martin Buchholz
On Mon, Sep 26, 2016 at 7:55 AM, Viktor Klang wrote: > >> > Test methods, >> > > Yeah, I thought so as well, but it turns out that when you have tons of > async tests, not being able to start new tests until either that timeout or > result makes for a very slow test

Re: We need to add blocking methods to CompletionStage!

2016-09-26 Thread Viktor Klang
On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz wrote: > No one is suggesting we add cancel to CompletionStage - I agree that would > break users, by making an immutable interface mutable. > +1 > This also means that CompletionStage cannot extend Future. > +1

Re: We need to add blocking methods to CompletionStage!

2016-09-26 Thread Viktor Klang
On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang wrote: > > > On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz > wrote: > >> No one is suggesting we add cancel to CompletionStage - I agree that >> would break users, by making an immutable interface

Re: We need to add blocking methods to CompletionStage!

2016-09-26 Thread Viktor Klang
On Sun, Sep 25, 2016 at 11:49 PM, Martin Buchholz wrote: > > > On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang > wrote: > >> >> PS. As a sidenote, Martin, and in all friendliness, "actor purist API"? >> C'mon, I know you're better than that!

Re: We need to add blocking methods to CompletionStage!

2016-09-24 Thread Martin Buchholz
No one is suggesting we add cancel to CompletionStage - I agree that would break users, by making an immutable interface mutable. This also means that CompletionStage cannot extend Future. I also would not want to have a toFuture method that would return a j.u.c.Future, because of misfit

Re: We need to add blocking methods to CompletionStage!

2016-09-24 Thread Viktor Klang
Hi Martin, *Unsurprisingly*, I think it is a bad idea to pollute something which was created as a non-blocking superset intended to provide maximum utility with minimum of sharp edges. However, I think you have a point in that toCompletableFuture throwing UOE is rather unhelpful, and if some

Re: We need to add blocking methods to CompletionStage!

2016-09-23 Thread Kasper Nielsen
> > Would not mind a CancellableCompletionStage interface > CancellableCompletionStage extends CompletionStage { > isCancelled(); > cancel(boolean) > } > > Just wanted to note. This is not just a question about functionality. It is also a signal to users about "hey this a computation you can

Re: We need to add blocking methods to CompletionStage!

2016-09-23 Thread Kasper Nielsen
On 21 September 2016 at 22:43, Martin Buchholz wrote: > (Sorry to re-open this discussion) > > The separation of a read-only CompletionStage from CompletableFuture is > great. I'm a fan of the scala style Promise/Future split as described in >

Re: We need to add blocking methods to CompletionStage!

2016-09-22 Thread Chris Hegarty
Until now CS and CF have not appeared in Java SE API signatures, outside of the j.u.c package. They are, however, currently being proposed for use in API signatures for Java SE 9 [1][2], namely j.l.Process[Handle]::onExit, and more extensively in the proposed new HTTP Client. CF was chosen, in