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
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
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
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
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!
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
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
>
> 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
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
>
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
10 matches
Mail list logo