You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DuckDBNative.java should call System.loadLibrary("duckdb_java"), starting faster if native lib is in -Djava.library.path #444
This may work out-of-the-box and be convenient for most users.
But it creates I/O and lag on each start, and fails if the system's security forbids loading binaries from /tmp.
Therefore I always extract native libs and store them uncompressed on disk in the java.library.path.
But the duckdb driver does not even try to load from java.library.path,
even if I delete the native libs from the jar file and the driver has no working option left.
Any other java lib with native lib(s) that I know does this correctly, only duckdb does not.
So I had to patch DuckDBNative.java myself:
Now it calls System.loadLibrary("duckdb_java") and works perfectly fine.
I kindly ask to fix this upstream.
Ideally, DuckDBNative.java should call System.loadLibrary("duckdb_java") first.
Only when this has failed shoud it upzip/copy the >60 MB from jar to /tmp.
This might even be more convenient for you duckdb developers than the current hack
System.load(Paths.get("build/debug", lib_res_name) ...
in the production duckdb_jdbc-1.4.1.0.jar, which works only if the native lib is not found as a resource (e.g. in the jar).
Additional suggestion:
Offer an alternative java driver jar that does NOT contain all the huge native libs for all the platforms,
and instead include the JNI binding library (which would be very small) in the DuckDB binary packages.
Then I (and others) could download that much smaller java jar, and build the DuckDB binary from source,
which allows "gcc -march=native" to optimize for the local CPU,
and feels safer than using a precompiled binary downloaded from the internet.
Activity
Support loading native lib directly from FS
staticlibs commentedon Nov 8, 2025
@giftick
Thanks for the report! Just FYI, there is an ongoing discussion on this topic in #450, more user input there is highly welcome.
Support loading native lib directly from FS
Support loading native lib directly from FS
Support loading native lib directly from FS (1.4)
Support loading native lib directly from FS (1.4)