I'm doing a http request with the jdk11 http client, but when I try to compile it, I got an error from the native-image command (`Error: No instances of http://javax.net.ssl.SSLContext are allowed in the image heap as this class should be initialized at image runtime`) I'm calling the same methods hato calls, I guess I'm missing something on my native-image configuration. @borkdude Since you mentioned you were able to compile a project with your hato-native fork, do you still have the configuration you used?
@jlle I used this fork: https://github.com/borkdude/hato-native
and compiled that with babashka. you probably need to enable ssl using a flag. let me check
probably this? https://github.com/borkdude/babashka/blob/master/script/compile#L49-L50
@borkdude Thanks for sharing it, I already had that options, I guess it has something to do with the --initialize-at-run-time
option
could try to initialize that class at runtime. unfortunately I threw away the hato branch of babashka
There is an issue about it here: https://github.com/oracle/graal/issues/1074
Recently there has been a PR to clj-http which presumably also solves this problem, could also look at that
or use clj-http-lite, babashka.curl, etc. but I guess you already considered those options
Thanks, I'll let you if I can find a solution, I already tried to initialize that class at run time, but still get the error. Most probably I'll end using clj-http-lite, but I wanted to try to find a solution for jdk11 client
hmm, is there a way to recover thrown away branches? let me check if I have it still on my computer...
got it!
https://github.com/borkdude/babashka/tree/hato-jdk11 so I only mapped these functions into babashka: https://github.com/borkdude/babashka/blob/hato-jdk11/src/babashka/impl/hato.clj
and I think that worked at the time.
I don't see anything special in the compile script
me neither, but thanks for pushing the branch, I just cloned it locally, in case you want to delete it again. Maybe has something to do with the graalvm version, I'm going to investigate a bit to see what I can find
you can clone it like:
git clone -b hato-jdk11 <ssh://git@github.com/borkdude/babashka> --recursive
Note it has submodulesI'll try to compile it locally to see if it still works
That was before clojure 1.10.2-alpha1. I'm getting the unbalanced monitor problem with that branch locally now. How did we get things done back then ;)
@jlle This works for me now, after running script/compile
:
./bb -e '(hato.client/get "<https://www.clojure.org>")'
I pushed a fix by bumping the Clojure version
compiled with GraalVM 20.1.0 jvm11
just using the compile script, right?
yes, script/compile
I'm trying it
if it's slow (> 5 minutes) try bumping the available memory:
export BABASHKA_XMX="-J-Xmx8g"
it just finished 🙂
yes, it works locally for me too
now I need to find what is different on my project, thanks a lot @borkdude
you can try compiling your GraalVM project with my hato fork
makes sense, I'll try that
hmm, wait, you didn't use hato, just the JDK 11 client right
yes, in my project I'm using jdk11 client directly
uhm, now I'm confused, I just added your hato fork to my project, and I can compile it and make requests. But I get an error compiling it if I use the jdk11 client directly. I'm just looking again to how hato makes the request, but I don't see any difference with my code
interesting
I found the reason, I was declaring my HttpClient globally, like this:
(def client (-> (HttpClient/newBuilder)
(.build)))
If I put the client creation in a let block inside a function, or wrap it in a delay
, I can compile it. But no idea why is thatI was suspecting something like that
compile time vs runtime initialization
I also get the error with your fork if I create a hato client in advance:
(def c (hato/build-http-client {}))
(hc/get "<https://httpbin.org/get>" {:http-client c})
thanks for figuring it out.
thanks for your help 🙂