Clojurians Log v2

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 https://github.com/seancorfield/next-jdbc/blob/develop/.github/workflows/test.yml#L28-L29 — but I was wondering what is common / reasonable at this point in terms of both GraalVM versions and Java bases?

@seancorfield usually I’m using the latest jdk11

And thanks for doing this :)

@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.

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

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 🙃

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

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

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

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

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 http://graalvm.org?

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

of those arrays, take the last values

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

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

oh I assumed native-image testing too…

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

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 https://github.com/lread/clj-graal-docs.

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

Yup! https://github.com/clj-commons/rewrite-clj/blob/main/.github/workflows/native-image-test.yml, 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 https://github.com/lread/clj-graal-docs/blob/master/doc/testing-strategies.md

Sci = test intepretation, pure = test compilation

@borkdude’s projects are also great references.

@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.

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

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

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

Cool, are the jdbc drivers sometimes a challenge?

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

The project I was referring to: https://github.com/babashka/babashka-sql-pods

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

So now I have:

build-graalvm-old:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        graalvm: [ '19.3.6', '20.3.2' ]
        base: [ 'java8', 'java11' ]
      ...

  build-graalvm-new:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        graalvm: [ '21.1.0' ]
        base: [ 'java11', 'java16' ]

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

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.