ci: update to GraalVM 23

[kkriske]

GraalVM 23.0.0 has been released.
This updates the CI to this version. This release should include oracle/graal#5932 which enables the native-exported flow on unix and darwin systems.

The org.graalvm.sdk:graal-sdk dependency in the pom is still set to 22.3.2, the latest release is compiled with java 17 so that would force anyone using native-image to use at least a java 17 jdk.
Going forward, GraalVM releases will follow the latest LTR releases from java, so the next version (23.1.0) will likely require java 21.

This is still a draft as the CI will keep failing because the graalvm/setup-graalvm action does not support the latest release yet: graalvm/setup-graalvm#45

[kkriske]

@gotson the linked GraalVM issue that should fix the native-exported flow on linux and macos does not work in the way I thought it works. It only works if you use System.loadLibrary. In order to do so, I added an additional last resort that uses this call, however it still seems to fail on MacOS and I am unsure why.

Edit: I did figure out why MacOS fails, see the linked GraalVM issue. The libraries for MacOS are packaged as a .jnilib file. This seems legacy from pre java 7 (https://bugs.openjdk.org/browse/JDK-7134701). The default naming now seems to be .dylib. Is it at all an option to change the libraries to the .dylib extension and remove the .jnilib name handling?

[kkriske]

@gotson Friendly reminder of the existence of this draft, to request your input on the previous comment.
If it's ok to rename the macos libraries I can move forward with this, otherwise it'll require either a temp workaround to rename the libary when unpacking them or this will have to wait until oracle/graal#6823 is merged and included in, hopefully, the next GraalVM release in september.

[gotson]

Thanks for the reminder, I'll try to have a look this week.

[gotson]

the latest release is compiled with java 17 so that would force anyone using native-image to use at least a java 17 jdk.
Going forward, GraalVM releases will follow the latest LTR releases from java, so the next version (23.1.0) will likely require java 21.

I am not familiar with GraalVM, what would be the impact of that ? My understanding is that it would impact projects using sqlite-jdbc, and wanting to compile to native, would be forced to used JDK17 (and later 21). The only downside i can think of is if the project compiles with an older JDK (like 8), but not with JDK17. If that's the case, i think that's a relatively small downside.

Edit: I did figure out why MacOS fails, see the linked GraalVM issue. The libraries for MacOS are packaged as a .jnilib file. This seems legacy from pre java 7 (https://bugs.openjdk.org/browse/JDK-7134701). The default naming now seems to be .dylib. Is it at all an option to change the libraries to the .dylib extension and remove the .jnilib name handling?

Thanks for the analysis. We should ditch .jnilib altogether, and use .dylib instead. That would better be done in a separate PR though, if you're up for the task?

[kkriske]

what would be the impact of that

I think your understanding is correct. A project using sqlite-jdbc that's compiling to java 8 wouldn't be a problem, because that project should at no point load the java classes compiled to JDK 11/17/21/.. The JDK version requirement is only enforced when actually using native-image.
And actually it won't really have an impact anymore, as for now the graal-sdk artefact will be compatible with JDK 11 (starting from the next 23.0.1 minor) so that doesn't change anything to the current compilation levels. It shouldn't be any problem staying on older graal-sdk versions either as the API should be stable.
The only time issues can arrise is if a new GraalVM version contains a breaking API change. Other than that, the minimal supported GraalVM version is dictated by whatever graal-sdk API calls and GraalVM features are actually used.

Thanks for the analysis. We should ditch .jnilib altogether, and use .dylib instead. That would better be done in a separate PR though, if you're up for the task?

I can look into that. My experience with makefiles is limitted, but it does seem like a fairly trivial change to do.

---

With those things cleared up, if we stay on graal-sdk:22.3.2 for now, combined with the library extension rename, the checks should be all green.

[gotson]

I can look into that. My experience with makefiles is limitted, but it does seem like a fairly trivial change to do.

I thought you already knew that's why I offered. Else I can take care of it, it shouldn't be too hard, mostly search and replace, and remove custom logic.

[kkriske]

I've created #939 for the jnilib -> dylib rename and cherrypicked the changed onto this PR so I can actually validate it works for this PR.

[gotson]

I've created #939 for the jnilib -> dylib rename and cherrypicked the changed onto this PR so I can actually validate it works for this PR.

merged, you can this rebase on master

[kkriske]

merged, you can this rebase on master

Rebased & marked as ready for review.

[gotson]

thanks @kkriske !