scala-java8-compat
scala-java8-compat copied to clipboard
Override mutating CompletableFuture methods to throw UOE
In private class CF[T] extends CompletableFuture[T] with (Try[T] => Unit) {
as an example.
So if a Java user downcasts to CompletableFuture, it won't go haywire.
@viktorklang Is this still relevant if we start to support toCompletableFuture
as proposed in #49 ?
No, I am still unsure what the actual behavior will be once we have 2 disparate completion venues (this Issue wants to remove one of the venues).
What's your thinking on how it ought to work?
I'm not 100% sure what problem we're trying to solve: I'd appreciate a test case to show what you mean by haywire.
Do you mean that a user might expect the following assertion to hold?
val p = Promise[String]()
val cs = toJava(p.future)
cs.asInstanceOf[CompletionStage].complete("done")
assert(p.isComplete)
That was what I was trying to explore in https://github.com/retronym/scala-java8-compat/commit/98054150e505dd1796273da9f270b12c5965c4c8
What happens when both the s.c.Future and the CompletableFuture gets completed, in different ordering?
What happens when obtrudeValue
/ obtrudeException
is used?
I think the semantics should be the same as if two places complete a completablefuture.
@retronym But obtrude
has different semantics?
I would really appreciate some help to get this right. As I'm not an expert in this domain, but I do understand test cases, would you be able to contribute some (passing or failing)? Otherwise, please assume I know nothing and elaborate a little bit more with your review comments :)
I won't be able to have a look at it until next week, if that's OK?
No probs, this isn't urgent, I just wanted to get the ball rolling.
Great, ping me on monday so we can see how to deal with this.
@viktorklang @retronym It's well past monday, just figured you would want a ping anyway?
LOL
Thanks @ryantheleach, I'll have a look at it when I can (swamped this week). :)