Load the SQLite JNI native library.
Neither of the obvious mechanisms works on a modern JVM:
So the jar ships a one-method Java shim (built by script/native-setup.sh): ensure-loaded! extracts the bundled native for this platform and asks the shim - a class in CApi's own classloader - to System.load it. CApi's static block is patched to a no-op install() call, so nothing else tries to load.
Without a bundled resource, the shim falls back to System.loadLibrary, honouring whatever java.library.path the host configured at launch.
Load the SQLite JNI native library. Neither of the obvious mechanisms works on a modern JVM: - System/loadLibrary searches java.library.path, which the JVM snapshots at startup - a jar-bundled library is invisible to it; - System/load called from our (dynamically compiled) Clojure code registers the library with the calling class's classloader, and CApi - a jar class - cannot bind natives from it. So the jar ships a one-method Java shim (built by script/native-setup.sh): ensure-loaded! extracts the bundled native for this platform and asks the shim - a class in CApi's own classloader - to System.load it. CApi's static block is patched to a no-op install() call, so nothing else tries to load. Without a bundled resource, the shim falls back to System.loadLibrary, honouring whatever java.library.path the host configured at launch.
(ensure-loaded!)Idempotent: load the SQLite JNI library for this platform from the bundled resource (or java.library.path when not bundled). Must run before any org.sqlite.jni.capi use; capi does that on entry.
Idempotent: load the SQLite JNI library for this platform from the bundled resource (or java.library.path when not bundled). Must run before any org.sqlite.jni.capi use; capi does that on entry.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |