https://github.com/xerial/sqlite-jdbc
Mentioning that because from (very) rough memory, Excel can work with JDBC too.
So if the ODBC approach doesn't work for someone, there's potentially another thing they can try. :)
Its very, very hip nowadays to worship Rust/Go and bash Java and gain HN karma from the younger generation while doing so, but at-least do it on real facts and not assumptions.
javac Sample.java && native-image -cp .:sqlite-jdbc-3.41.2.1.jar Sample
./sample
name = leo
id = 1
name = yui
id = 2
ls -al sample.db
-rw-r--r-- 1 OMIT OMIT 8192 Apr 1 22:22 sample.dbI just discontinued my Jetbrains subscription after 10 years or so. Now I'm using VS Code and don't miss anything. My reasons for switching to VS Code are unrelated to the costs but purely due to quality issues and missing or poorly implemented features:
1. For all Jetbrains IDEs, ISO keyboard layout with dead keys doesn't work on Ubuntu based distros. I was baffled when I found out after saying goodbye to Windows lately. When filing a bug I was asked to wade through years old pages of comments to find somewhere someone who posted a workaround that was not compatible with the Toolbox. Well, at least the support could have sent me the instructions to fix it to save me spending an hour to read those threads at Youtrack.
2. Vue 3 support was a disaster for itself. Still, Vue 3 support is very much behind the VS Code extension.
3. Same for Svelte. They are not even working on bugs / feature requests like intellisense in the templates.
4. Same for TailwindCSS. Never ending storing. Don't know and care if Jetbrains got it right by now.
5. Starting maybe 2 years ago, Jetbrains added feature for feature that were just distracting and annoying. This "run command in terminal" thingie for example. They're bloating their IDEs with new (mostly useless stuff) but don't fix essential bugs or get Webstorm back into shape.
6. Datagrip still doesn't (or maybe it does in the meantime) support SQLite STRICT TABLES (version 3.37). The simple answer from Jetbrains was: "The open source lib we're using does not support it so we don't." (Actually the lib (https://github.com/xerial/sqlite-jdbc) is currently unmaintained - another reason to be careful depending on a lib maintained by a single person.). The reply would be perfectly fine for an open source project, but not for a multi billion dollar company I as a customer had payed accumulated several thousand Euros in the last years.
I'm using mainly Go, Rust and several frontend frameworks. VS Code support for those is really good. Many things work much better in VS Code.
I know Android uses it a lot, so I opened up an Android project at my company and it looks like the android SDK comes with a bunch of SQLite abstractions, and it's not clear what the underlying driver is. But the SQLite official website ships an Android AAR so maybe that is it? (https://www.sqlite.org/2020/sqlite-android-3310100.aar)
This seems to be the main general-purpose JVM lib: https://github.com/xerial/sqlite-jdbc and it seems to be keeping in lockstep with the official SQLite versions (within a couple months).
Edit: Also can you elaborate on the "in a multiplatform way"? Maybe I'm having a brain-fart or memory-hole but shouldn't you not have to worry about that at all?
Edit2: Looks like there is a nice blurb in the docs on that github page:
Since sqlite-jdbc-3.6.19, the natively compiled SQLite engines will be used for the following operating systems:
Windows (Windows, x86 architecture, x86_64)
Mac OS X x86_64 (Support for SnowLeopard (i386) has been deprecated)
Linux x86, x86_64, arm (v5, v6, v7 and for android), ppc64
In the other OSs not listed above, the pure-java SQLite is used. (Applies to versions before 3.7.15)
If you want to use the native library for your OS, [build the source from scratch.[1] https://github.com/xerial/sqlite-jdbc [2] http://www.h2database.com/