scala/scala-java8-compat

Strange cast to completableFuture in example issue

Maatary opened this issue · 2 comments

Hi,

I would like to clarify something that sounds strange in the examples.

I'm a bit confused by the following statements when compared to some things done in the examples (see below, after the comments)

Note that the bridge is implemented at the read-only side of asynchronous
handles, namely scala.concurrent.Future instead of scala.concurrent.Promise
and CompletionStage instead of CompletableFuture. This is intentional, as
the semantics of bridging the write-handles would be prone to race
conditions; if both ends (CompletableFuture and Promise) are completed
independently at the same time, they may contain different values afterwards.
For this reason, toCompletableFuture() is not supported on the
created CompletionStages.

and

Returns a CompletionStage that will be completed with the same value or
exception as the given Scala Future when that completes.
Since the Future is a read-only representation,
this CompletionStage does not support the toCompletableFuture method.

In the test suite you can see things like:

@Test
public void testToJavaSuccess() throws InterruptedException,
        ExecutionException {
    final Promise<String> p = promise();
    final CompletionStage<String> cs = toJava(p.future());
    final CompletableFuture<String> cp = (CompletableFuture<String>) cs;
    assertFalse("cs must not yet be completed", cp.isDone());
    p.success("Hello");
    assertTrue("cs must be completed by now", cp.isDone());
    assertEquals("Hello", cp.get());
}

I do not understand this casting. Does the fact that cp is final protect it from being unsafe, which is the all point of the paragraph above. I mean cs.toCompletablefuture is forbidden. I have not tried the code yet, but i wonder if the compiler will enforce the read only of cp, and no setting method. I find it very very strange. How will it stop me from using complete(T value) ?

Is there a bug in the implementation or is it just a flaws. Because forbidding a conversation and doing it by casting, is strange.

tentatively closing, since it hasn't been made clear that there is an actionable issue here