Defining IDeref can break AOT compiled clojure projects.

[aphyr]

[aphyr]

Use http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Proxy.html at client initialization time to construct a proxy for promises here: https://github.com/aphyr/riemann-java-client/blob/master/src/main/java/com/aphyr/riemann/client/Promise.java

Remove IDeref from the inheritance chain of IPromise: https://github.com/aphyr/riemann-java-client/blob/master/src/main/java/com/aphyr/riemann/client/IPromise.java

[andrusieczko]

Hi @aphyr,

Any plans to fix this?

I've got a project with elastic search and wanted to update it to 2.2.0 and got the jar hell error due to IBlockingDeref class you define here:

https://github.com/aphyr/riemann-java-client/blob/master/riemann-java-client/src/main/java/clojure/lang/IBlockingDeref.java

In the newest elastic, you can't disable their JarHell, so I can't move on without fixing this issue.

Thanks,
Karol

P.S. I actually moved both interfaces to com.aphyr.riemann.client and everything works just fine. Please look at the #69.

[andrusieczko]

Hey,

So I spent some time on looking at this issue.

So there are two (three?) approaches I found.

1. Change map-promise method in client.clj:
   https://github.com/aphyr/riemann-clojure-client/compare/master...andrusieczko:map-promise-fix?expand=1

   So this works fine, all the tests are passing.

   Advantage: it's a small, simple change

   Downside: if someone wants to use RiemannClient instance directly, calling the java methods on it (like (.sendEvent ^IRiemannClient rc event)). Then result will be IPromise which won’t be subtype of clojure.lang.IDeref anymore.

2. Change the RiemannClient constructor methods to use proxy in client.clj:
   https://github.com/aphyr/riemann-clojure-client/compare/master...andrusieczko:deref-fix?expand=1

   Still a couple of things to be done there (no point of finishing it now):

   • all the constructor methods would need to use proxies
   • not all nested method calls (that return IPromise) still don't work

   Advantage: it should work for all the cases and the user doesn't have to know anything about the implementation

   Disadvantage: it's very complicated

3. Use Futures instead of Promises :)

Please let me know what you think about it and I can finish the implementation.

Regards,
Karol