Move CanIsolate CompletableFuture instance to 2.12+ only

[Avasil]

There might be also a flaky CompletableFuture test, I'll fix it as well

[oleg-py]

LGTM 👍

[Avasil]

I think CompletableFutureLocalSuite is failing because sometimes f doesn't get isolated reference before it is scheduled.

I will try to figure it out tomorrow but I am not familiar with CompletableFuture and why would it happen so if you guys have any ideas then go ahead :D

[oleg-py]

I vaguely remember that pool management in CompletableFuture is worse than it is in our Scala one, and it often falls back to its default global pool. Maybe we can't really support it, then.

[Avasil]

@oleg-py @alexandru

I vaguely remember that pool management in CompletableFuture is worse than it is in our Scala one, and it often falls back to its default global pool. Maybe we can't really support it, then.

Yup, I have been playing around and if we use thenCompose (equivalent of flatMap) it pretty much always uses ForkJoinPool.commonPool-worker-0 . Maybe it is still possible to support it but I don't think there is a lot of interest for it and it doesn't seem worth the effort right now. What do you think about removing the support in this PR? We can always revisit it later.

[oleg-py]

Yeah, let's do that.

[alexandru]

I vaguely remember that pool management in CompletableFuture is worse than it is in our Scala one, and it often falls back to its default global pool. Maybe we can't really support it, then.

Wait, what do you mean?

Is it our fault? Are we using global somewhere where we shouldn't?

[oleg-py]

Is it our fault?

No, Java 8 CompletableFuture uses it's own "global" (ForkJoinPool.commonPool()), and it's hard-coded in methods since Java doesn't have implicits - unless you pass your own on almost every method call, it will reschedule on that commonPool

[Avasil]

Also note that thenComposeAsync doesn't have a variant which takes a thread pool (at least to my very limited knowledge)

[Avasil]

I pushed a change to remove it so we can easily merge it if we decide to go this way

[oleg-py]

Yeah, I don't think we can or even should support anything that bypasses TracingScheduler.

[alexandru]

👍 yes, screw it.