What is your bb version and how are you executing the above code, in a script, repl?

babashka v1.0.168 and executing it in a socket repl

workaround:

(binding [*warn-on-reflection* *warn-on-reflection*]
  (require '[java-http-clj.core :as http]))

Awesome and will do, thanks!

The new parts I just finished are • interceptors https://github.com/babashka/http-client#interceptors • async https://github.com/babashka/http-client#async

(def resp (client/post "" {:body "From Clojure"}))
(json/parse-string (:body resp)) ;;=> {"args" {}, "data" "", ...}

I like how you handle POST file uploads with io/file or io/input-stream.

Is it possible to deref a CompletableFuture? In other words, is it possible to deref the result of an async get request?

@U3X7174KS I corrected the output, "From Clojure" was indeed missing

I don't think it's possible to directly implement IDeref for CompletableFuture but we could implement a wrapper like we did for process maybe...

oh wait, deref does work! :)

user=> (def fut (client/get "" {:async true}))
#'user/fut
user=> @future 

since it works on all java.util.concurrent.Future

updated README

At first, I expected that clj-http supported deref for getting the result of async requests. I see that's not the case, clj-http has callbacks. https://github.com/dakrone/clj-http#async-http-request

That Apache future doesn't derive from java.util.concurrent.Future

To implement chaining you can use something like this: https://github.com/babashka/http-client/blob/aa5b209e678b4d76e19f3d5e265533310a851515/src/babashka/http_client/internal.clj#L176 which I use internally to chain the interceptors onto the future

oh wait, that apache future also derives from java.util.concurrent.Future so I guess you could use deref there too

I guess we could support those callbacks too like this: https://github.com/schmee/java-http-clj/blob/master/src/java_http_clj/core.clj#L165-L168

cool! I haven't thought much of how separate of a concern it should technically be, but would you consider adding websocket functionality to this? Or would that belong in a different library that depends on this? In practice I often use both together and I like that java-http-clj offers it as a packaged deal

> would you consider adding websocket functionality to this? yes, todo

Just a side question, is it virtual thread friendly? I believe they changed underlying code on Java 19+ and it should be vthreads friendly.

http-client doesn't really do anything vthread specific - what underlying code did they change? CompletableFuture?

I believe they just changed internal implementation, API remains the same - in Java tradition. I recall Ron Pressler mentioned this, cannot really find the reference though.

Well, http-client doesn't use any hidden / private Java module stuff, so I think it should be ok? ;)

yeah, of course 🙂

It looks great 👏