Just looked at the Clojure test matrix and I see it testing against JDK 8 through 11. Is there a reason not to test against more recent JDKs?
our only official supported JDKs are the LTS releases
there are also some non-functional reasons which have to do with silly reasons like disk space and compute capacity on the build box
eventually we will take care of those but the pain involved is enough that I'm putting it off for now
I do manually test Clojure itself on every Java release
Thanks. We’re using OpenJDK 11 in production and have been discussing whether to upgrade to 14 which we’ve used fairly extensively in dev or whether to wait for 17. There’s no pressing reason either way really at this point. I’ve been using 15 for dev for ages now and I’m thinking of updating to 16 soon.
15 and 16 are really amazing IMHO -- ZGC garbage collector is worth it almost alone
Corretto is already on 16 but annoyingly not supported across various AWS offerings (we use Elastic Beanstalk, I guess they wait for an LTS version)
We are using shenandoah, with JDK15 on production and our GC pauses on AVG are less than 1ms, Shenandoah has better handling of degradation state than ZGC (on our tests ZGC with high requests spikes enters more quickly in a degraded state with worse pauses than Shenandoah)
@niwinz It sounds like that is not available in all builds of JDK15, based on a quick search. I found a SO post about it that suggests it’s in Oracle’s JDK and Adopt’s OpenJDK but not part of the standard OpenJDK? Good to know it is production-solid though.
It is available in all builds (with exception of builds from oracle, because the obvious reason: it competes with ZGC I think....); adoptopenjdk, corretto, azul, redhat, all them comes with it
We started using ZGC, but after many tests and some issues in production (mainly on big load spikes), we have seen many degraded states with very big pauses. Shenandoah, has a more deterministic, tiered degraded states when garbage is generated more quickly than cleared. With shenandoah we have not seen any issue.
over shenandoah?
dunno, haven't evaluated shenanoah much
Is ZGC the default now, with 16?
no. It became "production" quality in 15, and has 1ms pause times in 16
Ah, cool. Right now, on 11, we specify -XX:+UseG1GC -XX:MaxGCPauseMillis=100
so having 1ms instead would be real nice 🙂
Maybe I’ll take 16 for a spin, on dev at least.
anyone is welcome to do anything they like, that I don't have to run :)
@souenzzo I already test several of my OSS projects against multiple JDKs: https://github.com/seancorfield/next-jdbc/blob/develop/.github/workflows/test.yml#L10
(guess I should change that to '16', '17-ea'
now)
and add graalvm as well )
Do you have an example of doing that in a GH Action?
give me a sec
name: Clojure CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
java: [ '8', '11', '14', '15', '16-ea', '17-ea' ]
steps:
- uses: actions/checkout@v2
- name: Setup Java
uses: actions/setup-java@v1
with:
java-version: ${{ matrix.java }}
- name: Setup Clojure
uses: DeLaGuardo/setup-clojure@master
with:
tools-deps: '1.10.1.739'
- name: Run Tests
run: clojure -M:test:runner
build-graalvm:
runs-on: ubuntu-latest
strategy:
matrix:
graalvm: [ '19.3.0', '20.0.0', '20.1.0', '20.2.0', '20.3.0', '20.3.1', '20.3.1.2', '21.0.0', '21.0.0.2' ]
base: [ 'java8', 'java11' ]
steps:
- uses: actions/checkout@v2
- name: Setup GraalVM
uses: DeLaGuardo/setup-graalvm@4.0
with:
graalvm: ${{ matrix.graalvm }}
java: ${{ matrix.base }}
- name: Setup Clojure
uses: DeLaGuardo/setup-clojure@master
with:
tools-deps: '1.10.1.739'
- name: Run Tests
run: clojure -M:test:runner
something like thatThanks @delaguardo!
You're welcome)
I will check this action in an hour. Not sure that I recall every version correctly