Wrapping future #44
Comments
|
/cc @rkuhn, who contributed this part of the library. |
|
The current approach was meant to be minimal, but we might have to bite the bullet. Writing a fully optimized version will be very painful, though. |
retronym
added a commit
to retronym/scala-java8-compat
that referenced
this issue
Jul 28, 2015
Makes `toJava.toScala` and `toScala.toJava` a wrap-and-unwrap operation, rather than a wrap-and-rewrap. This won't be possible if we merge scala#46, which speaks in favour of reverting the change that finalized `DefaultPromise` in Scala 2.12.x. This patch does not attempt to "wrap the Future with an implementation of CompletionStage that delegates to Future", as Jame's proposed in issue scala#44, which seems tricky or at least tedious to implement.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm wondering why
FutureConverters.toJavacreates a newCompletableFuture, rather than simply wrapping theFuturewith an implementation ofCompletionStagethat delegates toFuture? Doing this would make conversion a little more efficient, and would mean conversions back and forth could be optimised so a conversion from a previously convertedCompletionStagetoFuturewould simply unwrap theFuture.The latter especially will be useful in Play, since we want to allow both Java and Scala code to intercept requests, and mixing these interceptors will potentially mean lots of conversions back and forth between the types. If it's just a simple wrapping/unwrapping, then we don't need to worry about the cost associated with it, otherwise we may end up with long chains of Futures and CompletionStages that add nothing to the actual value except overhead.
The text was updated successfully, but these errors were encountered: