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  --recursive

I'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 "")'

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)))

I 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 "" {:http-client c})

thanks for figuring it out.

thanks for your help 🙂