Welcome! Please see the About page for a little more info on how this works.

+1 vote
in Java Interop by

I'm running into a situation where I would need to mix CompletableFutures in with Clojure futures/delays/etc. Unfortunately, IPending is an interface, which can't be extended to Java core classes.

For IDeref and IBlockingDeref, it's not a problem working with Java Futures, because the deref fn supports them.

Couldn't the same be done with the realized? fn? Currently, it only works with IPending. It would be ideal if it matched the deref behavior and called .isDone() when given a java.util.concurrent.Future.

1 Answer

0 votes
by

Whenever anyone brings up realized? in discussions on Slack, the general advice is that you shouldn't use it and it already doesn't work in an intuitive way in many situations.

The question then usually turns to "Why are you using realized? in the first place?".

An example of non-intuitive behavior:

https://ask.clojure.org/index.php/10004/calling-realized-delay-currently-executing-blocks-caller

(considered a bug -- fixed in Clojure 1.11)

I just checked our 125k line codebase and there's just one call to realized? in a test, specifically checking whether a promise was delivered or not.

I'll be interested to hear what folks from the Clojure Team say about this but I suspect they wouldn't want to encourage use of it?

by
Thanks for responding, Sean. I appreciate it.

Still, the bug with `delay` was fixed, yes? I searched around on Slack, and all the warnings I saw about `realized?` only applied to seqs: variant returns from things like `range`, what `realized?` should mean in the presence of partial realization, etc... but none of that applies to a Java Future.

Handling j.u.c.Futures wouldn't make `realized?` *more* problematic, unless encouraging its use counts.

It's not a big deal, I asked more out of surprise at the lack of input parity between `deref` and `realized?` than any burning need.
Welcome to Clojure Q&A, where you can ask questions and receive answers from members of the Clojure community.
...