Avoid completableFuture.asScala crash for MinimalStage

[lrytz]

CompletableFuture.completedStage creates a MinimalStage instance which extends CompletableFuture and overrides most methods with UnsupportedOperationException.

Calling toCompletableFuture on it creates a fresh CompletableFuture.

Fixes scala/bug#12918.

[He-Pin]

I will fix it in other repo this weekend

[He-Pin]

I was missed this @DougLea

[He-Pin]

lgtm

[som-snytt]

Thanks for the opportunity to read up on these interfaces I'd managed to avoid all these years.

The issue is exactly this concluding line of JavaDoc:

This interface does not define methods for initially creating, forcibly completing normally or exceptionally, probing completion status or results, or awaiting completion of a stage. Implementations of CompletionStage may provide means of achieving such effects, as appropriate. Method toCompletableFuture enables interoperability among different implementations of this interface by providing a common conversion type.

That is obscure, but says don't call isDone. If you want to do these things, use toCompletableFuture. The phrase "common conversion type" is not meaningful to me, even though the context is conversions. But presumably it means what you already discovered, that there may be various CompletionStage implementations of variable abilities, and convert to a CF for interoperability.

The other "object lesson" (pun alert) is why did we ever think it's OK to downcast to runtime types? On the one hand, we can despise Java's penchant for implementing an interface by throwing unsupported operations, such as iterator.remove when it's not supported by a collection. On the other hand, we can only trust the (compile time) type we're given as a value parameter. The exception is probing for the private wrapper type.

[som-snytt]

Despite the hiccup, it was pleasant to see the previous optimization and the benchmarking.

My last question is why do we downcast at all if I can always call CompletionStage#toCompetableFuture#isDone? Any completion stage can tell me (via the "common conversion type") whether a value is available.

Since it's only an optimization of sorts, approving forthwith.

[lrytz]

My last question is why do we downcast at all if I can always call CompletionStage#toCompetableFuture#isDone? Any completion stage can tell me (via the "common conversion type") whether a value is available.

Maybe toCompetableFuture is more likely to be a no-op if we only call it on CompletableFutures, so there could be a performance benefit? I don't know.