ci: update native-image testing to GraalVM 21

[kkriske]

Update the native-image GitHub Actions flow to test against GraalVM 21 instead of GraalVM 20.
The change of the org.graalvm.sdk:graal-sdk to org.graalvm.sdk:nativeimage is a rename described here: https://www.graalvm.org/release-notes/JDK_21#refactoring-graalvm-sdk

[gotson]

@kkriske before i can look into this i may need you to help me on https://github.com/xerial/sqlite-jdbc/actions/runs/6391166703/job/17345891110

i added slf4j-api as a dependency, and it seems to be breaking the native build.

[kkriske]

@gotson You can try and follow the exception, and add --trace-class-initialization=org.slf4j.LoggerFactory and --trace-class-initialization=ch.qos.logback.classic.Logger to the native-image arguments. That should give more insights. Since it's logger related it's probably got to do something with static logger fields in build-time classes.

I'm currently on a work trip so it'll be a week before I can look at it more closely.

[gotson]

@gotson You can try and follow the exception, and add --trace-class-initialization=org.slf4j.LoggerFactory and --trace-class-initialization=ch.qos.logback.classic.Logger to the native-image arguments. That should give more insights. Since it's logger related it's probably got to do something with static logger fields in build-time classes.

I'm currently on a work trip so it'll be a week before I can look at it more closely.

Thanks, i think i managed to fix it via 89dbda1

hopefully i did the right thing ! CI is now green.

[kkriske]

hopefully i did the right thing ! CI is now green.

config in maven just for tests should be fine. I would argue against adding RuntimeClassInitialization.initializeAtBuildTime(LoggerFactory.class); to the feature. You shouldn't directly configure anything outside your own codebase, this can conflict with the existing configuration of an end user (or from logback itself if they decide to bundle one) which would prevent them from using sqlite-jdbc.
It's especially dangerous to mark external things for build-time initialization because you're not in charge of what code will be run (maybe the end user overrides the logback version) and this could have unintended consequences.

In the end the user will also get the same build error you got, and they'll have to fix it in the way they want.
I'll take a look next week if there's anything I can do to prevent the error it alltogether.

[kkriske]

@gotson I've put my take on the build issue in this PR: #985