Scala future to Java Completable future

[Maatary Okouya]

Hi,

1 - is there any lib or recommendation on our to go from Scala future to Java Completable future ?

I have a legacy system that i need to adapt to a scala lib that returns futures in its API.

2 -Also i was wondering how the intricacy between threadPool executor works. By intricacy i mean, the fact that from the legacy java app i would be working on the forkjoin common Pool and that scala lib has his own ThreadPool executors.

This last question is something i always wonder, how the communication between thread poolexecutor happens. In java you can somewhat poll, cancel future, so would you do that from another context.

Maatari

[Viktor Klang]

Hi Maatary,

On Thu, Nov 5, 2015 at 3:58 PM, Maatary Okouya <maatar...@gmail.com> wrote:

Hi,

1 - is there any lib or recommendation on our to go from Scala future to Java Completable future ?

I have a legacy system that i need to adapt to a scala lib that returns futures in its API.

https://github.com/scala/scala-java8-compat

 

2 -Also i was wondering how the intricacy between threadPool executor works. By intricacy i mean, the fact that from the legacy java app i would be working on the forkjoin common Pool and that scala lib has his own ThreadPool executors.

I'm sorry but I don't understand the question.

 

This last question is something i always wonder, how the communication between thread poolexecutor happens. In java you can somewhat poll, cancel future, so would you do that from another context

I don't understand this either, could you elaborate/rephrase?

 

Maatari

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Cheers,

√

[Maatary Okouya]

Thank you Viktor. 

Concerning the second point, i might be making a problem out of something that is not :) . 

Maybe simply speaking: Does it cause an issue to let say wait for the completion of a future that is executed on another threadPool? 

I am in ThreadPool A, executing a future task A1 that spawn a future task B1 in the ThreadPool B. 

a - Then A1 wait for B1

b- A1 attach an onComplete/CallBack on B1 (via a map for instance), in which threadPool that callBack will be executed. 

Finally by polling i meant checking things with isDone (Java Version) for instance. 

[Viktor Klang]

On Thu, Nov 5, 2015 at 4:31 PM, Maatary Okouya <maatar...@gmail.com> wrote:

Thank you Viktor. 

Concerning the second point, i might be making a problem out of something that is not :) . 

Maybe simply speaking: Does it cause an issue to let say wait for the completion of a future that is executed on another threadPool? 

I am in ThreadPool A, executing a future task A1 that spawn a future task B1 in the ThreadPool B. 

a - Then A1 wait for B1

What do you mean by "wait" here?

 

b- A1 attach an onComplete/CallBack on B1 (via a map for instance), in which threadPool that callBack will be executed. 

The callback will be executed on the thread pool passed in implicitly to the call to onComplete/map etc.

--

Cheers,

√

[Maatary Okouya]

By wait i meant Await.result for instance. 

I will figure that point myself or come back after re-reading some materials that are related.

[Maatary Okouya]

Concerning the link you sent. I have a question maybe you do have the answer to it. 

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, <code>toCompletableFuture()</code> 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 <code>toCompletableFuture</code> 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. It is strange.

On Thursday, November 5, 2015 at 10:15:28 AM UTC-5, √iktor Klang wrote:

[Viktor Klang]

My rule of thumb for Await.result is: Only ever use it when you know why you don't have a choice not to.

[Viktor Klang]

Casting the CompletionStage to a CompletableFuture is equivalent of casing any interface to its concrete type, once you do, all bets are off unless you know exactly what you're doing.