[concurrency-interest] CompletableFuture in Java 8
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:
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