Discuss GraalVM related topics. Use clojure 1.10.2 or newer for all new projects. Contribute to and GraalVM slack:
seancorfield 2021-04-30T04:26:22.140300Z

Hi folks! Thanks to @delaguardo I am adding GraalVM to next.jdbc’s test matrix and I went with the example set of versions and Java bases that he provided — see — but I was wondering what is common / reasonable at this point in terms of both GraalVM versions and Java bases?

borkdude 2021-04-30T06:44:52.141200Z

@seancorfield usually I’m using the latest jdk11

borkdude 2021-04-30T06:45:10.141700Z

And thanks for doing this :)


Nice combination of technologies! Do you have a specific use case for this combination? I’m curious what drove you here 😅

lread 2021-04-30T15:37:43.147900Z

@seancorfield, for rewrite-clj, I was testing with GraalVM latest JDK8 and JDK11, but am currently dropping JDK8 GraalVM tests (I never tested JDK8 on on Windows because it was too cumbersome to install, and JDK8 is no longer available for macOS with the current GraalVM release). I find GitHub Actions is nice in that it lets me run my tests on Windows, macOS and Ubuntu. GitHub Actions also has a relatively generous 7gb of RAM which can come in handy if your native-image compile happens to be RAM-hungry.

lread 2021-04-30T15:38:31.148800Z

Note also that the current GraalVM release is 21.1.0 which I don’t see in the code snippit you provided.

borkdude 2021-04-30T15:39:31.150600Z

On the other hand, a library like next.jdbc should be able to compile with only 4gb, so giving it 7gb might prevent you from detecting weird problems 🙃

lread 2021-04-30T15:39:32.150700Z

Also GraalVM 21.1.0 includes an experimental JDK16 release. I won’t bother with this and will wait for their JDK17 release.

borkdude 2021-04-30T15:40:03.151100Z

I think it would be sane to test JDK11 + GraalVM LTS and GraalVM latest

borkdude 2021-04-30T15:40:22.151500Z

(but I would be perfectly happy with only JDK11 + latest)

lread 2021-04-30T15:43:33.152100Z

Ya @borkdude, I am going with your perfectly happy route. :simple_smile:

seancorfield 2021-04-30T16:02:50.153400Z

Thanks @lee @borkdude Is there any value in testing against those intermediate versions, rather than just the three that are easily available for d/l from

graalvm: [ '19.3.6', '20.3.2', '21.1.0' ]
        base: [ 'java8', 'java11' ]

borkdude 2021-04-30T16:03:32.153600Z

of those arrays, take the last values

lread 2021-04-30T16:04:26.154600Z

that’s my approach too, just GraalVM 21.1.0 java11.

borkdude 2021-04-30T16:04:27.154700Z

oh I see you are going to test the JVM version with graal, this isn't about native?

lread 2021-04-30T16:05:56.155100Z

oh I assumed native-image testing too…

seancorfield 2021-04-30T16:06:47.155700Z

I have no idea — which is why I’m here asking 🙂 — I just followed @delaguardo’s notes.

lread 2021-04-30T16:09:59.157700Z

So my GraalVM tests for rewrite-clj are to verify that that rewrite-clj still works after being compiled to a native binary by GraalVM’s native-image. GraalVM is more that just native-image though, but that’s what we typically talk about here and cover on

seancorfield 2021-04-30T16:15:14.158300Z

@lee Do you have a GH Actions file for that?

lread 2021-04-30T16:18:12.160Z

Yup!, it reaches out to scripts written in Babashka. You might want to ignore my sci tests and focus on pure tests, but I did describe both testing strategies up on

lread 2021-04-30T16:19:05.161Z

Sci = test intepretation, pure = test compilation

lread 2021-04-30T16:19:32.161500Z

@borkdude’s projects are also great references.

borkdude 2021-04-30T16:20:59.163100Z

@seancorfield I usually make CLIs with graalvm and those a pretty easy to test by just making a clojure function which shell out to that CLI and then test for the correctly printed value. I then use normal clojure.test to run tests. This is how I can re-use tests for both the JVM and native. Both combinations can be then run on each OS including Windows. This is how I do it for clj-kondo, babashka, and jet.

lread 2021-04-30T16:22:43.164100Z

We call that testing strategy “conditional spawing” up on clj-graal-docs.

borkdude 2021-04-30T16:22:44.164200Z

Rewrite-clj is a library so that is obviously a bit different and can be tested like @lee described it.

borkdude 2021-04-30T16:23:17.164500Z

FWIW I am testing next.jdbc in one of my projects natively as well by using it as a library, against various databases

lread 2021-04-30T16:24:10.165Z

Cool, are the jdbc drivers sometimes a challenge?

borkdude 2021-04-30T16:25:52.165400Z

yes, they are the main challenge, because they often rely on reflection

borkdude 2021-04-30T16:26:19.165600Z

The project I was referring to:

seancorfield 2021-04-30T16:34:01.168500Z

I don’t know enough about GraalVM to follow what’s going on in rewrite-clj’s GH Actions file and the supporting .clj for the native test so at this point I think I’ll just have next.jdbc run tests against the various versions like @delaguardo suggested and leave it up to users of next.jdbc to do native image tests if that’s what they are building (as @borkdude does).

seancorfield 2021-04-30T16:35:02.169Z

So now I have:

    runs-on: ubuntu-latest
        graalvm: [ '19.3.6', '20.3.2' ]
        base: [ 'java8', 'java11' ]

    runs-on: ubuntu-latest
        graalvm: [ '21.1.0' ]
        base: [ 'java11', 'java16' ]

lread 2021-04-30T16:39:13.172100Z

That seems reasonable, but I’m not sure there is huge value to JVM testing against GraalVM JDKs. (Someone tell me I’m wrong, I am ok with being wrong :simple_smile:). I don’t think it hurts, but it might be just as good as testing against various AdoptOpenJDK versions (8, 11, 16)?

lread 2021-04-30T16:43:26.174700Z

Also: it was not a minor effort for me to setup GraalVM native-image testing for rewrite-clj, those were earlier days, but still, it took time. You could consider just pointing to @borkdude’s project from your docs as an example of it being possible to run next.jdbc when compiled by GraalVM native-image.