Right, it's more of a JVM issue which affects scala. I did a search a while (couple years?) ago and maybe just didn't find the right materials, but they all (in my now-vague memory) seemed awkward and/or were not portable across platforms. Does this approach let you do every kind of sqlite operation, as completely as if from the interactive native client or as if calling it from C? Who maintains it and is it kept in sync with the C version? (Maybe I'll go look that up, but if you already know...) Thanks much for the info.

Edit: ps (maybe a note to myself as much as anything in case I go look up this stuff): And does sqlite run in the same process as the app? Can the app process control the db location?

I don't really know the answer to those questions. But I know SQLite is heavily used in almost every ecosystem so I would be really surprised if there were real blockers.

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.

I think I had found that one, but didn't actually try it. By multiplatform way, I meant avoiding native libraries (sounds like more maintenance and debugging over time) and still being able to run on OpenBSD (or any BSD), linux, windows, and mac, at least.

Edit: yes, I think it does not currently run on OpenBSD, etc. One could contribute that library, but in that case, I'm more inclined to learn Rust and not deal with the JVM at all. Then I also get convenient access to things like pledge() and unveil(), and other OS-specific system calls, when I want. :) I will be grateful, however, for further correction & enlightenment... :)

(Edit2: I have been reading "the book" in Rust, but probably should write a test to confirm that it will make calls to sqlite and pledge() as directly as I think, using the tools I found.)