Superseded by https://clojure.atlassian.net/browse/CLJ-2799

Bumping this ticket because it interests me as well.

Do I understand correctly that it is undesirable to extend IFn interface to java.util.function.* interfaces because it can potentially break existing external implementors of IFn?

If I could just use IFn's anywhere a java.util.function.* was needed, that would be fantastic!

Moving to Java 8 as a baseline allows us to use default interface methods.

The `some-java-fns-interface.patch` patch implements Consumer, Function, Predicate and Supplier on IFn.

If you want to go this route, I would be very happy to implement all interfaces under java.util.function on IFn as well as the accompanying tests. I currently use this code to play with FoundationDB through its Java client and it works well for me.

https://github.com/marctrem/clojure/commit/97742493f674edd8f6c034ee94da84fa62a76bad

Another possible avenue is to extend java.util.function.Supplier to Clojure functions with an explicit 0-arity. That interface is becoming increasingly common in practice; it might be valuable to special-case it. (We shouldn't & couldn't do a similar thing for defrecords, as they already have a method called get, which clashes with Supplier's only method.)