[concurrency-interest] CompletableFuture in Java 8

thurstonn thurston at nomagicsoftware.com
Wed Dec 3 17:33:29 EST 2014

So, I'll put in my 2c (might not even be worth that).

Would it really be so . . . unprincipled . . . to add a get() method to
CompletionStage (and overloaded variants)?  Or at least an isDone() method
(I'm assuming that that would *not* need to block, or wait)

I think that is what Josh is essentially advocating (cancel() is more
problematic I agree).

I guess I just think about writing tests; if you're going to expose
CompletionStage as return types from API methods, the most simple and
obvious way to test the implementation is:

CompletionStage do(some-input)

assert expected == do(...).get()

Viktor's suggested work-around:
val cf = new CompletableFuture<R>()
stage.whenComplete((r, e) -> if (e != null) cf.completeExceptionally(e) else

is just evil IMHO.
Although the CDL code that Doug references is even worse.
What should the test code do, put in arbitrary Thread.sleeps()?  Blecch

And I think Josh's point that blocking (invoking get()) is *orthogonal* to
the ability for a reader/consumer to *write* the value of a computation,
which is what the admittedly "escape hatch" of #toCompletableFuture()
exposes, is correct.

I'm not dismissing Viktor's concerns, and you can be sure that there would
be engineers who would end up doing:

CompletionStage cs1 = . . .
result = cs1.get()

CompletionStage cs2 = . . . (result)

and so on (which might result in inter-engineer violent crimes).

Maybe I just can't let go of bad habits, but although I admire the goal of
*never block*, at least in the applications I write, I'm not sure if it's
realistic (I'd love to eliminate side effects as well, but I need a
database, or to write to a socket, etc).

Even Erlang apps block sometimes (cf. gen_server:call())

View this message in context: http://jsr166-concurrency.10961.n7.nabble.com/CompletableFuture-in-Java-8-tp11414p11569.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.

More information about the Concurrency-interest mailing list