Skip to content

Conversation

@staticlibs
Copy link
Collaborator

This change makes the following arch-specific artifacts to be deployed to Maven Central (in addition to the main duckdb_jdbc-x.x.x.x.jar that remains unchanged), classifiers:

  • linux_amd64
  • linux_amd64_musl
  • linux_arm64
  • linux_arm64_musl
  • macos_universal
  • windows_amd64
  • windows_arm64

Each arch-specific artifact contains a native library only for this
particular platform and can be specified in Maven dependencies with the
following syntax:

<dependency>
   <groupId>org.duckdb</groupId>
   <artifactId>duckdb_jdbc</artifactId>
   <version>1.x.x.x</version>
   <classifier>linux_amd64_musl</classifier>
</dependency>

Note that Windows and Linux-musl AArch64 artifacts are renamed from aarch64 to arm64 to align with wider DuckDB arch naming.

Additionally an artifact without any native library is deployed with a nolib classifier. It is intended to be used with an externally provided native library, see #421 for details.

This change makes the following arch-specific artifacts to be deployed
to Maven Central (in addition to the main `duckdb_jdbc-x.x.x.x.jar` that
remains unchanged), classifiers:

 - `linux_amd64`
 - `linux_amd64_musl`
 - `linux_arm64`
 - `linux_arm64_musl`
 - `macos_universal`
 - `windows_amd64`
 - `windows_arm64`

 Each arch-specific artifact contains a native library only for this
 particular platform and can be specified in Maven dependencies with the
 following syntax:

 ```xml
 <dependency>
    <groupId>org.duckdb</groupId>
    <artifactId>duckdb_jdbc</artifactId>
    <version>1.x.x.x</version>
    <classifier>linux_amd64_musl</classifier>
</dependency>
 ```

Note that Windows and Linux-musl AArch64 artifacts are renamed from
`aarch64` to `arm64` to align with wider DuckDB arch naming.

Additionally an artifact without any native library is deployed with a
`nolib` classifier. It is intended to be used with an externally
provided native library, see duckdb#421 for details.
@staticlibs staticlibs merged commit d00260e into duckdb:main Nov 7, 2025
10 checks passed
@staticlibs staticlibs deleted the maven_nolib branch November 7, 2025 14:27
staticlibs added a commit to staticlibs/duckdb-java that referenced this pull request Nov 7, 2025
This PR is a continuation of duckdb#447 PR to allow using
`duckdb_jdbc-x.x.x.x-nolib.jar` along with a JNI native library, that
is loaded directly from file system.

It extends the idea from duckdb#421 (and supersedes it) implementing the
following logic:

1. if the driver JAR has a bundled native library (for current JVM
   os/arch), then this library will be unpacked to the temporary
   directory and loaded from there. If the library cannot be unpacked or
   loaded - there is no fallback to other methods (it is expected that
   `-nolib` JAR is used for other loading methods)

2. if the driver JAR does not hava a native library bundled inside it,
   then it will check whether a JNI native libary with the DuckDB
   internal naming (like `libduckdb_java.so_linux_amd64`) exists in
   file system next to the driver JAR (in the same directory). If
   library file is found there - then the driver will attempt to load
   it. If the file is found in file system, then it is expected that is
   can be loaded and there is no fallback to loading by name.

3. if the native lib is not found in the same directory, then, like in
   duckdb#421, the driver tries to load it using `duckdb_java` name (that will
   be translated by JVM to a platform-specific name like
   `libduckdb_java.so`).

Testing: new test added that covers loading from the same dir and
loading by name.

Fixes: duckdb#444
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant