graalvm

Discuss GraalVM related topics. Use clojure 1.10.2 or newer for all new projects. Contribute to https://github.com/clj-easy/graal-docs and https://github.com/BrunoBonacci/graalvm-clojure. GraalVM slack: https://www.graalvm.org/slack-invitation/.
jose 2020-07-24T09:30:08.089600Z

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?

borkdude 2020-07-24T09:34:39.090Z

@jlle I used this fork: https://github.com/borkdude/hato-native

borkdude 2020-07-24T09:35:06.090600Z

and compiled that with babashka. you probably need to enable ssl using a flag. let me check

borkdude 2020-07-24T09:35:55.090800Z

probably this? https://github.com/borkdude/babashka/blob/master/script/compile#L49-L50

jose 2020-07-24T09:43:09.092400Z

@borkdude Thanks for sharing it, I already had that options, I guess it has something to do with the --initialize-at-run-time option

borkdude 2020-07-24T09:44:53.093700Z

could try to initialize that class at runtime. unfortunately I threw away the hato branch of babashka

borkdude 2020-07-24T09:46:25.094600Z

There is an issue about it here: https://github.com/oracle/graal/issues/1074

borkdude 2020-07-24T09:46:57.095300Z

Recently there has been a PR to clj-http which presumably also solves this problem, could also look at that

borkdude 2020-07-24T09:48:59.096600Z

or use clj-http-lite, babashka.curl, etc. but I guess you already considered those options

jose 2020-07-24T09:50:51.098200Z

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

borkdude 2020-07-24T09:51:45.099Z

hmm, is there a way to recover thrown away branches? let me check if I have it still on my computer...

borkdude 2020-07-24T09:52:44.099200Z

got it!

1🎉
borkdude 2020-07-24T09:54:35.100100Z

and I think that worked at the time.

borkdude 2020-07-24T09:54:40.100300Z

I don't see anything special in the compile script

jose 2020-07-24T09:57:52.102Z

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

borkdude 2020-07-24T09:58:47.102400Z

you can clone it like:

git clone -b hato-jdk11 <ssh://git@github.com/borkdude/babashka> --recursive
Note it has submodules

borkdude 2020-07-24T09:59:00.102700Z

I'll try to compile it locally to see if it still works

borkdude 2020-07-24T10:01:48.103400Z

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

borkdude 2020-07-24T10:04:53.103900Z

@jlle This works for me now, after running script/compile:

./bb -e '(hato.client/get "<https://www.clojure.org>")'

borkdude 2020-07-24T10:05:05.104200Z

I pushed a fix by bumping the Clojure version

borkdude 2020-07-24T10:06:06.104700Z

compiled with GraalVM 20.1.0 jvm11

jose 2020-07-24T10:06:40.105200Z

just using the compile script, right?

borkdude 2020-07-24T10:06:46.105400Z

yes, script/compile

jose 2020-07-24T10:07:02.105600Z

I'm trying it

borkdude 2020-07-24T10:11:15.106400Z

if it's slow (> 5 minutes) try bumping the available memory:

export BABASHKA_XMX="-J-Xmx8g"

jose 2020-07-24T10:14:01.106800Z

it just finished 🙂

jose 2020-07-24T10:14:18.107100Z

yes, it works locally for me too

jose 2020-07-24T10:15:07.107900Z

now I need to find what is different on my project, thanks a lot @borkdude

borkdude 2020-07-24T10:15:22.108200Z

you can try compiling your GraalVM project with my hato fork

jose 2020-07-24T10:16:35.108700Z

makes sense, I'll try that

borkdude 2020-07-24T10:24:15.109200Z

hmm, wait, you didn't use hato, just the JDK 11 client right

jose 2020-07-24T10:26:56.109700Z

yes, in my project I'm using jdk11 client directly

jose 2020-07-24T10:36:52.112100Z

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

borkdude 2020-07-24T10:44:14.112300Z

interesting

jose 2020-07-24T11:16:37.112900Z

I found the reason, I was declaring my HttpClient globally, like this:

(def client (-&gt; (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 that

borkdude 2020-07-24T11:18:29.113100Z

I was suspecting something like that

borkdude 2020-07-24T11:18:53.113400Z

compile time vs runtime initialization

jose 2020-07-24T11:19:04.113600Z

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

borkdude 2020-07-24T11:19:31.113800Z

thanks for figuring it out.

jose 2020-07-24T11:19:58.114200Z

thanks for your help 🙂