This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-04-30
Channels
- # asami (10)
- # babashka (14)
- # beginners (71)
- # calva (56)
- # cider (8)
- # cljs-dev (3)
- # clojure (111)
- # clojure-australia (1)
- # clojure-europe (19)
- # clojure-nl (4)
- # clojure-uk (147)
- # clojurescript (4)
- # cursive (8)
- # datalog (1)
- # datomic (19)
- # emacs (4)
- # graalvm (32)
- # helix (14)
- # jackdaw (7)
- # jobs-discuss (10)
- # juxt (4)
- # lsp (3)
- # malli (47)
- # meander (6)
- # off-topic (29)
- # portal (6)
- # re-frame (1)
- # react (3)
- # reitit (24)
- # releases (1)
- # remote-jobs (4)
- # reveal (33)
- # rewrite-clj (3)
- # shadow-cljs (5)
- # sql (10)
- # tools-deps (4)
- # vim (7)
- # xtdb (151)
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
@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.
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' ]
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
@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.
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
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 ). 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.