It won't be easy (even the pgsql supports only the happy path). Usually major lifting is done by java folks around frameworks like micronaut or quarkus or spring boot. Search their blogs for tips.
btw, I have been able to get postgres support into babashka: https://clojurians.slack.com/archives/CLX41ASCS/p1587675201407300 more info here: https://github.com/borkdude/babashka/issues/372
@peterschwarz Did you manage to get sqlite to work at all though?
Not, yet, though I’ll take a look at your postgres work - it might give me some hints
postgres was by far the easiest to get going with graalvm, also because I found a working example from @yogthos
mysql requires a sh*t-ton of reflection config and it still didn't work
same with sqlite, from what I’ve seen
pg is the only one I could get jdbc to work with as well
With sqlite, I think the biggest hurdle is getting it to load the native library
Which, side question, is there any way to write those graal reflection classes using
Seemed like I was running into some classpath issues on that front
@peterschwarz you don't need to generate classes, you just have to list them in a reflection-config.json file
Do those just go into a resources directory?
you can also use an agent to discover those classes using a runtime example
I think what was leading me down that path was this: https://github.com/mageddo/graalvm-examples/blob/59f1f1bf09894681edfddaa100b4504770ad0685/sqlite/src/main/java/com/mageddo/sqlite/JNIReflectionClasses.java
I take it one is able to express the same thing with just those json files?
I’ll have to take another stab at this tonight…
My primary struggle with this was that most libraries that have multiplatform natives embedded first copy the appropriate platform one to a temp directory and
loadLibrary from there — I couldn’t figure out how to replicate that in graal at runtime. It may only work if
sqlite or whatever exists on the system already, which is much less pain-free for the user
Yeah, I’m definitely fine with that approach