GH-882: Add support for loading native library from a user specified location by pepijnve · Pull Request #883 · apache/arrow-java

pepijnve · 2025-10-10T07:57:53Z

What's Changed

Add an opt-in code path that attempts to load the native library relative to the path specified by the arrow.cdata.library.path system property.

Closes#882.

lidavidm · 2025-10-10T08:06:33Z

Is there precedent for this kind of flag in other JNI libraries?

pepijnve · 2025-10-10T08:20:07Z

Is there precedent for this kind of flag in other JNI libraries?

See for instance https://github.com/xerial/sqlite-jdbc/blob/755cf1d0223a83b97909fca43c8027e3e02bc021/src/main/java/org/sqlite/SQLiteJDBCLoader.java#L300 and https://github.com/jnr/jffi/blob/master/src/main/java/com/kenai/jffi/internal/StubLoader.java#L302

A possible alternative could be to check java.library.path indirectly by calling System.load first in the try/catch block. I did not go for this option since it might make existing systems pick up a library from somewhere unintentionally. The custom system property makes this explicitly opt-in.

As described in the issue, loading executable code from /tmp is problematic since it's sometimes forbidden by security settings of the host OS. This is an actual deployment problem for the system I work on since we have no control over those settings.

lidavidm · 2025-10-10T10:17:47Z

Thanks. I'll give this a fuller review but if there's precedent then the idea is good by me.

lidavidm · 2025-10-13T01:18:17Z

+ return;
+ }
+ } catch (UnsatisfiedLinkError e) {
+ // Ignore this error and fall back to extracting from the JAR file


Actually, would it be better to error if the property is provided but the file doesn't exist? That way you don't unexpectedly/silently fall back when you intended to load from somewhere else.

In my specific application the native library will be have been stripped from the jar and loading will fail so the end result will be the same either way.
I modeled this on examples like the ones I referenced where possible alternatives are tried in a specified order. Happy to change this to fail early though. Let me know what you would prefer.

Hmm, we can leave it as is then.

lidavidm · 2025-10-13T10:44:48Z

Ah, the JNI CI is still broken for now...we can queue this for after #865

lidavidm · 2025-10-13T11:17:44Z

Ah but in the meantime do you mind helping the linter out?

Error: Failed to execute goal com.diffplug.spotless:spotless-maven-plugin:2.44.4:check (spotless-check) on project arrow-c-data: The following files had format violations:
Error: src/main/java/org/apache/arrow/c/jni/JniLoader.java
Error: @@ -91,8 +91,7 @@
Error: ······}
Error: ····}
Error: Error: -····final·String·libraryToLoad·=
Error: -········name·+·"/"·+·getNormalizedArch()·+·"/"·+·libraryName;
Error: +····final·String·libraryToLoad·=·name·+·"/"·+·getNormalizedArch()·+·"/"·+·libraryName;
Error: ····try·{
Error: ······File·temp·=
Error: ··········File.createTempFile("jnilib-",·".tmp",·new·File(System.getProperty("java.io.tmpdir")));
Error: Run 'mvn spotless:apply' to fix these violations.
Error: -> [Help 1]

lidavidm · 2025-10-27T11:23:51Z

Ok, please rebase and CI should be fixed!

…ed location

lidavidm

CI failure is #893

pepijnve · 2025-10-10T07:57:53Z

What's Changed

Add an opt-in code path that attempts to load the native library relative to the path specified by the arrow.cdata.library.path system property.

Closes#882.

lidavidm · 2025-10-10T08:06:33Z

Is there precedent for this kind of flag in other JNI libraries?

pepijnve · 2025-10-10T08:20:07Z

Is there precedent for this kind of flag in other JNI libraries?

See for instance https://github.com/xerial/sqlite-jdbc/blob/755cf1d0223a83b97909fca43c8027e3e02bc021/src/main/java/org/sqlite/SQLiteJDBCLoader.java#L300 and https://github.com/jnr/jffi/blob/master/src/main/java/com/kenai/jffi/internal/StubLoader.java#L302

A possible alternative could be to check java.library.path indirectly by calling System.load first in the try/catch block. I did not go for this option since it might make existing systems pick up a library from somewhere unintentionally. The custom system property makes this explicitly opt-in.

As described in the issue, loading executable code from /tmp is problematic since it's sometimes forbidden by security settings of the host OS. This is an actual deployment problem for the system I work on since we have no control over those settings.

lidavidm · 2025-10-10T10:17:47Z

Thanks. I'll give this a fuller review but if there's precedent then the idea is good by me.

lidavidm · 2025-10-13T01:18:17Z

+ return;
+ }
+ } catch (UnsatisfiedLinkError e) {
+ // Ignore this error and fall back to extracting from the JAR file


Actually, would it be better to error if the property is provided but the file doesn't exist? That way you don't unexpectedly/silently fall back when you intended to load from somewhere else.

In my specific application the native library will be have been stripped from the jar and loading will fail so the end result will be the same either way.
I modeled this on examples like the ones I referenced where possible alternatives are tried in a specified order. Happy to change this to fail early though. Let me know what you would prefer.

Hmm, we can leave it as is then.

lidavidm · 2025-10-13T10:44:48Z

Ah, the JNI CI is still broken for now...we can queue this for after #865

lidavidm · 2025-10-13T11:17:44Z

Ah but in the meantime do you mind helping the linter out?

Error: Failed to execute goal com.diffplug.spotless:spotless-maven-plugin:2.44.4:check (spotless-check) on project arrow-c-data: The following files had format violations:
Error: src/main/java/org/apache/arrow/c/jni/JniLoader.java
Error: @@ -91,8 +91,7 @@
Error: ······}
Error: ····}
Error: Error: -····final·String·libraryToLoad·=
Error: -········name·+·"/"·+·getNormalizedArch()·+·"/"·+·libraryName;
Error: +····final·String·libraryToLoad·=·name·+·"/"·+·getNormalizedArch()·+·"/"·+·libraryName;
Error: ····try·{
Error: ······File·temp·=
Error: ··········File.createTempFile("jnilib-",·".tmp",·new·File(System.getProperty("java.io.tmpdir")));
Error: Run 'mvn spotless:apply' to fix these violations.
Error: -> [Help 1]

lidavidm · 2025-10-27T11:23:51Z

Ok, please rebase and CI should be fixed!

…ed location

lidavidm

CI failure is #893

pepijnve · 2025-10-10T07:57:53Z

What's Changed

Add an opt-in code path that attempts to load the native library relative to the path specified by the arrow.cdata.library.path system property.

Closes#882.

lidavidm · 2025-10-10T08:06:33Z

Is there precedent for this kind of flag in other JNI libraries?

pepijnve · 2025-10-10T08:20:07Z

Is there precedent for this kind of flag in other JNI libraries?

See for instance https://github.com/xerial/sqlite-jdbc/blob/755cf1d0223a83b97909fca43c8027e3e02bc021/src/main/java/org/sqlite/SQLiteJDBCLoader.java#L300 and https://github.com/jnr/jffi/blob/master/src/main/java/com/kenai/jffi/internal/StubLoader.java#L302

A possible alternative could be to check java.library.path indirectly by calling System.load first in the try/catch block. I did not go for this option since it might make existing systems pick up a library from somewhere unintentionally. The custom system property makes this explicitly opt-in.

As described in the issue, loading executable code from /tmp is problematic since it's sometimes forbidden by security settings of the host OS. This is an actual deployment problem for the system I work on since we have no control over those settings.

lidavidm · 2025-10-10T10:17:47Z

Thanks. I'll give this a fuller review but if there's precedent then the idea is good by me.

lidavidm · 2025-10-13T01:18:17Z

+ return;
+ }
+ } catch (UnsatisfiedLinkError e) {
+ // Ignore this error and fall back to extracting from the JAR file


Actually, would it be better to error if the property is provided but the file doesn't exist? That way you don't unexpectedly/silently fall back when you intended to load from somewhere else.

In my specific application the native library will be have been stripped from the jar and loading will fail so the end result will be the same either way.
I modeled this on examples like the ones I referenced where possible alternatives are tried in a specified order. Happy to change this to fail early though. Let me know what you would prefer.

Hmm, we can leave it as is then.

lidavidm · 2025-10-13T10:44:48Z

Ah, the JNI CI is still broken for now...we can queue this for after #865

lidavidm · 2025-10-13T11:17:44Z

Ah but in the meantime do you mind helping the linter out?

Error: Failed to execute goal com.diffplug.spotless:spotless-maven-plugin:2.44.4:check (spotless-check) on project arrow-c-data: The following files had format violations:
Error: src/main/java/org/apache/arrow/c/jni/JniLoader.java
Error: @@ -91,8 +91,7 @@
Error: ······}
Error: ····}
Error: Error: -····final·String·libraryToLoad·=
Error: -········name·+·"/"·+·getNormalizedArch()·+·"/"·+·libraryName;
Error: +····final·String·libraryToLoad·=·name·+·"/"·+·getNormalizedArch()·+·"/"·+·libraryName;
Error: ····try·{
Error: ······File·temp·=
Error: ··········File.createTempFile("jnilib-",·".tmp",·new·File(System.getProperty("java.io.tmpdir")));
Error: Run 'mvn spotless:apply' to fix these violations.
Error: -> [Help 1]

lidavidm · 2025-10-27T11:23:51Z

Ok, please rebase and CI should be fixed!

…ed location

lidavidm

CI failure is #893

pepijnve · 2025-10-10T07:57:53Z

What's Changed

Add an opt-in code path that attempts to load the native library relative to the path specified by the arrow.cdata.library.path system property.

Closes#882.

lidavidm · 2025-10-10T08:06:33Z

Is there precedent for this kind of flag in other JNI libraries?

pepijnve · 2025-10-10T08:20:07Z

Is there precedent for this kind of flag in other JNI libraries?

See for instance https://github.com/xerial/sqlite-jdbc/blob/755cf1d0223a83b97909fca43c8027e3e02bc021/src/main/java/org/sqlite/SQLiteJDBCLoader.java#L300 and https://github.com/jnr/jffi/blob/master/src/main/java/com/kenai/jffi/internal/StubLoader.java#L302

A possible alternative could be to check java.library.path indirectly by calling System.load first in the try/catch block. I did not go for this option since it might make existing systems pick up a library from somewhere unintentionally. The custom system property makes this explicitly opt-in.

As described in the issue, loading executable code from /tmp is problematic since it's sometimes forbidden by security settings of the host OS. This is an actual deployment problem for the system I work on since we have no control over those settings.

lidavidm · 2025-10-10T10:17:47Z

Thanks. I'll give this a fuller review but if there's precedent then the idea is good by me.

lidavidm · 2025-10-13T01:18:17Z

+ return;
+ }
+ } catch (UnsatisfiedLinkError e) {
+ // Ignore this error and fall back to extracting from the JAR file


Actually, would it be better to error if the property is provided but the file doesn't exist? That way you don't unexpectedly/silently fall back when you intended to load from somewhere else.

In my specific application the native library will be have been stripped from the jar and loading will fail so the end result will be the same either way.
I modeled this on examples like the ones I referenced where possible alternatives are tried in a specified order. Happy to change this to fail early though. Let me know what you would prefer.

Hmm, we can leave it as is then.

lidavidm · 2025-10-13T10:44:48Z

Ah, the JNI CI is still broken for now...we can queue this for after #865

lidavidm · 2025-10-13T11:17:44Z

Ah but in the meantime do you mind helping the linter out?

Error: Failed to execute goal com.diffplug.spotless:spotless-maven-plugin:2.44.4:check (spotless-check) on project arrow-c-data: The following files had format violations:
Error: src/main/java/org/apache/arrow/c/jni/JniLoader.java
Error: @@ -91,8 +91,7 @@
Error: ······}
Error: ····}
Error: Error: -····final·String·libraryToLoad·=
Error: -········name·+·"/"·+·getNormalizedArch()·+·"/"·+·libraryName;
Error: +····final·String·libraryToLoad·=·name·+·"/"·+·getNormalizedArch()·+·"/"·+·libraryName;
Error: ····try·{
Error: ······File·temp·=
Error: ··········File.createTempFile("jnilib-",·".tmp",·new·File(System.getProperty("java.io.tmpdir")));
Error: Run 'mvn spotless:apply' to fix these violations.
Error: -> [Help 1]

lidavidm · 2025-10-27T11:23:51Z

Ok, please rebase and CI should be fixed!

…ed location

lidavidm

CI failure is #893

pepijnve · 2025-10-10T07:57:53Z

What's Changed

Add an opt-in code path that attempts to load the native library relative to the path specified by the arrow.cdata.library.path system property.

Closes#882.

lidavidm · 2025-10-10T08:06:33Z

Is there precedent for this kind of flag in other JNI libraries?

pepijnve · 2025-10-10T08:20:07Z

Is there precedent for this kind of flag in other JNI libraries?

See for instance https://github.com/xerial/sqlite-jdbc/blob/755cf1d0223a83b97909fca43c8027e3e02bc021/src/main/java/org/sqlite/SQLiteJDBCLoader.java#L300 and https://github.com/jnr/jffi/blob/master/src/main/java/com/kenai/jffi/internal/StubLoader.java#L302

A possible alternative could be to check java.library.path indirectly by calling System.load first in the try/catch block. I did not go for this option since it might make existing systems pick up a library from somewhere unintentionally. The custom system property makes this explicitly opt-in.

As described in the issue, loading executable code from /tmp is problematic since it's sometimes forbidden by security settings of the host OS. This is an actual deployment problem for the system I work on since we have no control over those settings.

lidavidm · 2025-10-10T10:17:47Z

Thanks. I'll give this a fuller review but if there's precedent then the idea is good by me.

lidavidm · 2025-10-13T01:18:17Z

+ return;
+ }
+ } catch (UnsatisfiedLinkError e) {
+ // Ignore this error and fall back to extracting from the JAR file


Actually, would it be better to error if the property is provided but the file doesn't exist? That way you don't unexpectedly/silently fall back when you intended to load from somewhere else.

In my specific application the native library will be have been stripped from the jar and loading will fail so the end result will be the same either way.
I modeled this on examples like the ones I referenced where possible alternatives are tried in a specified order. Happy to change this to fail early though. Let me know what you would prefer.

Hmm, we can leave it as is then.

lidavidm · 2025-10-13T10:44:48Z

Ah, the JNI CI is still broken for now...we can queue this for after #865

lidavidm · 2025-10-13T11:17:44Z

Ah but in the meantime do you mind helping the linter out?

Error: Failed to execute goal com.diffplug.spotless:spotless-maven-plugin:2.44.4:check (spotless-check) on project arrow-c-data: The following files had format violations:
Error: src/main/java/org/apache/arrow/c/jni/JniLoader.java
Error: @@ -91,8 +91,7 @@
Error: ······}
Error: ····}
Error: Error: -····final·String·libraryToLoad·=
Error: -········name·+·"/"·+·getNormalizedArch()·+·"/"·+·libraryName;
Error: +····final·String·libraryToLoad·=·name·+·"/"·+·getNormalizedArch()·+·"/"·+·libraryName;
Error: ····try·{
Error: ······File·temp·=
Error: ··········File.createTempFile("jnilib-",·".tmp",·new·File(System.getProperty("java.io.tmpdir")));
Error: Run 'mvn spotless:apply' to fix these violations.
Error: -> [Help 1]

lidavidm · 2025-10-27T11:23:51Z

Ok, please rebase and CI should be fixed!

…ed location

lidavidm

CI failure is #893

pepijnve · 2025-10-10T07:57:53Z

What's Changed

Add an opt-in code path that attempts to load the native library relative to the path specified by the arrow.cdata.library.path system property.

Closes#882.

lidavidm · 2025-10-10T08:06:33Z

Is there precedent for this kind of flag in other JNI libraries?

pepijnve · 2025-10-10T08:20:07Z

Is there precedent for this kind of flag in other JNI libraries?

See for instance https://github.com/xerial/sqlite-jdbc/blob/755cf1d0223a83b97909fca43c8027e3e02bc021/src/main/java/org/sqlite/SQLiteJDBCLoader.java#L300 and https://github.com/jnr/jffi/blob/master/src/main/java/com/kenai/jffi/internal/StubLoader.java#L302

A possible alternative could be to check java.library.path indirectly by calling System.load first in the try/catch block. I did not go for this option since it might make existing systems pick up a library from somewhere unintentionally. The custom system property makes this explicitly opt-in.

As described in the issue, loading executable code from /tmp is problematic since it's sometimes forbidden by security settings of the host OS. This is an actual deployment problem for the system I work on since we have no control over those settings.

lidavidm · 2025-10-10T10:17:47Z

Thanks. I'll give this a fuller review but if there's precedent then the idea is good by me.

lidavidm · 2025-10-13T01:18:17Z

+ return;
+ }
+ } catch (UnsatisfiedLinkError e) {
+ // Ignore this error and fall back to extracting from the JAR file


Actually, would it be better to error if the property is provided but the file doesn't exist? That way you don't unexpectedly/silently fall back when you intended to load from somewhere else.

In my specific application the native library will be have been stripped from the jar and loading will fail so the end result will be the same either way.
I modeled this on examples like the ones I referenced where possible alternatives are tried in a specified order. Happy to change this to fail early though. Let me know what you would prefer.

Hmm, we can leave it as is then.

lidavidm · 2025-10-13T10:44:48Z

Ah, the JNI CI is still broken for now...we can queue this for after #865

lidavidm · 2025-10-13T11:17:44Z

Ah but in the meantime do you mind helping the linter out?

Error: Failed to execute goal com.diffplug.spotless:spotless-maven-plugin:2.44.4:check (spotless-check) on project arrow-c-data: The following files had format violations:
Error: src/main/java/org/apache/arrow/c/jni/JniLoader.java
Error: @@ -91,8 +91,7 @@
Error: ······}
Error: ····}
Error: Error: -····final·String·libraryToLoad·=
Error: -········name·+·"/"·+·getNormalizedArch()·+·"/"·+·libraryName;
Error: +····final·String·libraryToLoad·=·name·+·"/"·+·getNormalizedArch()·+·"/"·+·libraryName;
Error: ····try·{
Error: ······File·temp·=
Error: ··········File.createTempFile("jnilib-",·".tmp",·new·File(System.getProperty("java.io.tmpdir")));
Error: Run 'mvn spotless:apply' to fix these violations.
Error: -> [Help 1]

lidavidm · 2025-10-27T11:23:51Z

Ok, please rebase and CI should be fixed!

…ed location

lidavidm

CI failure is #893

pepijnve · 2025-10-10T07:57:53Z

What's Changed

Add an opt-in code path that attempts to load the native library relative to the path specified by the arrow.cdata.library.path system property.

Closes#882.

lidavidm · 2025-10-10T08:06:33Z

Is there precedent for this kind of flag in other JNI libraries?

pepijnve · 2025-10-10T08:20:07Z

Is there precedent for this kind of flag in other JNI libraries?

See for instance https://github.com/xerial/sqlite-jdbc/blob/755cf1d0223a83b97909fca43c8027e3e02bc021/src/main/java/org/sqlite/SQLiteJDBCLoader.java#L300 and https://github.com/jnr/jffi/blob/master/src/main/java/com/kenai/jffi/internal/StubLoader.java#L302

A possible alternative could be to check java.library.path indirectly by calling System.load first in the try/catch block. I did not go for this option since it might make existing systems pick up a library from somewhere unintentionally. The custom system property makes this explicitly opt-in.

As described in the issue, loading executable code from /tmp is problematic since it's sometimes forbidden by security settings of the host OS. This is an actual deployment problem for the system I work on since we have no control over those settings.

lidavidm · 2025-10-10T10:17:47Z

Thanks. I'll give this a fuller review but if there's precedent then the idea is good by me.

lidavidm · 2025-10-13T01:18:17Z

+ return;
+ }
+ } catch (UnsatisfiedLinkError e) {
+ // Ignore this error and fall back to extracting from the JAR file


Actually, would it be better to error if the property is provided but the file doesn't exist? That way you don't unexpectedly/silently fall back when you intended to load from somewhere else.

In my specific application the native library will be have been stripped from the jar and loading will fail so the end result will be the same either way.
I modeled this on examples like the ones I referenced where possible alternatives are tried in a specified order. Happy to change this to fail early though. Let me know what you would prefer.

Hmm, we can leave it as is then.

lidavidm · 2025-10-13T10:44:48Z

Ah, the JNI CI is still broken for now...we can queue this for after #865

lidavidm · 2025-10-13T11:17:44Z

Ah but in the meantime do you mind helping the linter out?

Error: Failed to execute goal com.diffplug.spotless:spotless-maven-plugin:2.44.4:check (spotless-check) on project arrow-c-data: The following files had format violations:
Error: src/main/java/org/apache/arrow/c/jni/JniLoader.java
Error: @@ -91,8 +91,7 @@
Error: ······}
Error: ····}
Error: Error: -····final·String·libraryToLoad·=
Error: -········name·+·"/"·+·getNormalizedArch()·+·"/"·+·libraryName;
Error: +····final·String·libraryToLoad·=·name·+·"/"·+·getNormalizedArch()·+·"/"·+·libraryName;
Error: ····try·{
Error: ······File·temp·=
Error: ··········File.createTempFile("jnilib-",·".tmp",·new·File(System.getProperty("java.io.tmpdir")));
Error: Run 'mvn spotless:apply' to fix these violations.
Error: -> [Help 1]

lidavidm · 2025-10-27T11:23:51Z

Ok, please rebase and CI should be fixed!

…ed location

lidavidm

CI failure is #893

pepijnve · 2025-10-10T07:57:53Z

What's Changed

Add an opt-in code path that attempts to load the native library relative to the path specified by the arrow.cdata.library.path system property.

Closes#882.

lidavidm · 2025-10-10T08:06:33Z

Is there precedent for this kind of flag in other JNI libraries?

pepijnve · 2025-10-10T08:20:07Z

Is there precedent for this kind of flag in other JNI libraries?

See for instance https://github.com/xerial/sqlite-jdbc/blob/755cf1d0223a83b97909fca43c8027e3e02bc021/src/main/java/org/sqlite/SQLiteJDBCLoader.java#L300 and https://github.com/jnr/jffi/blob/master/src/main/java/com/kenai/jffi/internal/StubLoader.java#L302

A possible alternative could be to check java.library.path indirectly by calling System.load first in the try/catch block. I did not go for this option since it might make existing systems pick up a library from somewhere unintentionally. The custom system property makes this explicitly opt-in.

As described in the issue, loading executable code from /tmp is problematic since it's sometimes forbidden by security settings of the host OS. This is an actual deployment problem for the system I work on since we have no control over those settings.

lidavidm · 2025-10-10T10:17:47Z

Thanks. I'll give this a fuller review but if there's precedent then the idea is good by me.

lidavidm · 2025-10-13T01:18:17Z

+ return;
+ }
+ } catch (UnsatisfiedLinkError e) {
+ // Ignore this error and fall back to extracting from the JAR file


Actually, would it be better to error if the property is provided but the file doesn't exist? That way you don't unexpectedly/silently fall back when you intended to load from somewhere else.

In my specific application the native library will be have been stripped from the jar and loading will fail so the end result will be the same either way.
I modeled this on examples like the ones I referenced where possible alternatives are tried in a specified order. Happy to change this to fail early though. Let me know what you would prefer.

Hmm, we can leave it as is then.

lidavidm · 2025-10-13T10:44:48Z

Ah, the JNI CI is still broken for now...we can queue this for after #865

lidavidm · 2025-10-13T11:17:44Z

Ah but in the meantime do you mind helping the linter out?

Error: Failed to execute goal com.diffplug.spotless:spotless-maven-plugin:2.44.4:check (spotless-check) on project arrow-c-data: The following files had format violations:
Error: src/main/java/org/apache/arrow/c/jni/JniLoader.java
Error: @@ -91,8 +91,7 @@
Error: ······}
Error: ····}
Error: Error: -····final·String·libraryToLoad·=
Error: -········name·+·"/"·+·getNormalizedArch()·+·"/"·+·libraryName;
Error: +····final·String·libraryToLoad·=·name·+·"/"·+·getNormalizedArch()·+·"/"·+·libraryName;
Error: ····try·{
Error: ······File·temp·=
Error: ··········File.createTempFile("jnilib-",·".tmp",·new·File(System.getProperty("java.io.tmpdir")));
Error: Run 'mvn spotless:apply' to fix these violations.
Error: -> [Help 1]

lidavidm · 2025-10-27T11:23:51Z

Ok, please rebase and CI should be fixed!

…ed location

lidavidm

CI failure is #893

pepijnve requested review from jbonofre, laurentgo, lidavidm and wgtmac as code owners October 10, 2025 07:57

pepijnve changed the title ~~Add support for loading native library from a user specified location~~GH-882: Add support for loading native library from a user specified locationOct 10, 2025

This comment has been minimized.
Sign in to view

lidavidm added the enhancement PRs that add or improve features. label Oct 10, 2025

github-actionsBot added this to the 18.4.0 milestone Oct 10, 2025

lidavidm approved these changes Oct 13, 2025
View reviewed changes

lidavidm reviewed Oct 13, 2025
View reviewed changes

pepijnve force-pushed the issue_882 branch from 4ea9861 to 27958cdCompare October 13, 2025 15:59

apache#882Add support for loading native library from a user specifi…
73c1f47
…ed location

pepijnve force-pushed the issue_882 branch from 27958cd to 73c1f47Compare October 27, 2025 13:06

lidavidm approved these changes Oct 27, 2025
View reviewed changes

lidavidm merged commit ed81e59 into apache:mainOct 27, 2025
23 of 25 checks passed

pepijnve requested review from jbonofre, laurentgo, lidavidm and wgtmac as code owners October 10, 2025 07:57

pepijnve changed the title ~~Add support for loading native library from a user specified location~~GH-882: Add support for loading native library from a user specified locationOct 10, 2025

This comment has been minimized.
Sign in to view

lidavidm added the enhancement PRs that add or improve features. label Oct 10, 2025

github-actionsBot added this to the 18.4.0 milestone Oct 10, 2025

lidavidm approved these changes Oct 13, 2025
View reviewed changes

lidavidm reviewed Oct 13, 2025
View reviewed changes

pepijnve force-pushed the issue_882 branch from 4ea9861 to 27958cdCompare October 13, 2025 15:59

apache#882Add support for loading native library from a user specifi…
73c1f47
…ed location

pepijnve force-pushed the issue_882 branch from 27958cd to 73c1f47Compare October 27, 2025 13:06

lidavidm approved these changes Oct 27, 2025
View reviewed changes

lidavidm merged commit ed81e59 into apache:mainOct 27, 2025
23 of 25 checks passed

pepijnve requested review from jbonofre, laurentgo, lidavidm and wgtmac as code owners October 10, 2025 07:57

pepijnve changed the title ~~Add support for loading native library from a user specified location~~GH-882: Add support for loading native library from a user specified locationOct 10, 2025

This comment has been minimized.
Sign in to view

lidavidm added the enhancement PRs that add or improve features. label Oct 10, 2025

github-actionsBot added this to the 18.4.0 milestone Oct 10, 2025

lidavidm approved these changes Oct 13, 2025
View reviewed changes

lidavidm reviewed Oct 13, 2025
View reviewed changes

pepijnve force-pushed the issue_882 branch from 4ea9861 to 27958cdCompare October 13, 2025 15:59

apache#882Add support for loading native library from a user specifi…
73c1f47
…ed location

pepijnve force-pushed the issue_882 branch from 27958cd to 73c1f47Compare October 27, 2025 13:06

lidavidm approved these changes Oct 27, 2025
View reviewed changes

lidavidm merged commit ed81e59 into apache:mainOct 27, 2025
23 of 25 checks passed

pepijnve requested review from jbonofre, laurentgo, lidavidm and wgtmac as code owners October 10, 2025 07:57

pepijnve changed the title ~~Add support for loading native library from a user specified location~~GH-882: Add support for loading native library from a user specified locationOct 10, 2025

This comment has been minimized.
Sign in to view

lidavidm added the enhancement PRs that add or improve features. label Oct 10, 2025

github-actionsBot added this to the 18.4.0 milestone Oct 10, 2025

lidavidm approved these changes Oct 13, 2025
View reviewed changes

lidavidm reviewed Oct 13, 2025
View reviewed changes

pepijnve force-pushed the issue_882 branch from 4ea9861 to 27958cdCompare October 13, 2025 15:59

apache#882Add support for loading native library from a user specifi…
73c1f47
…ed location

pepijnve force-pushed the issue_882 branch from 27958cd to 73c1f47Compare October 27, 2025 13:06

lidavidm approved these changes Oct 27, 2025
View reviewed changes

lidavidm merged commit ed81e59 into apache:mainOct 27, 2025
23 of 25 checks passed

pepijnve requested review from jbonofre, laurentgo, lidavidm and wgtmac as code owners October 10, 2025 07:57

pepijnve changed the title ~~Add support for loading native library from a user specified location~~GH-882: Add support for loading native library from a user specified locationOct 10, 2025

This comment has been minimized.
Sign in to view

lidavidm added the enhancement PRs that add or improve features. label Oct 10, 2025

github-actionsBot added this to the 18.4.0 milestone Oct 10, 2025

lidavidm approved these changes Oct 13, 2025
View reviewed changes

lidavidm reviewed Oct 13, 2025
View reviewed changes

pepijnve force-pushed the issue_882 branch from 4ea9861 to 27958cdCompare October 13, 2025 15:59

apache#882Add support for loading native library from a user specifi…
73c1f47
…ed location

pepijnve force-pushed the issue_882 branch from 27958cd to 73c1f47Compare October 27, 2025 13:06

lidavidm approved these changes Oct 27, 2025
View reviewed changes

lidavidm merged commit ed81e59 into apache:mainOct 27, 2025
23 of 25 checks passed

pepijnve requested review from jbonofre, laurentgo, lidavidm and wgtmac as code owners October 10, 2025 07:57

pepijnve changed the title ~~Add support for loading native library from a user specified location~~GH-882: Add support for loading native library from a user specified locationOct 10, 2025

This comment has been minimized.
Sign in to view

lidavidm added the enhancement PRs that add or improve features. label Oct 10, 2025

github-actionsBot added this to the 18.4.0 milestone Oct 10, 2025

lidavidm approved these changes Oct 13, 2025
View reviewed changes

lidavidm reviewed Oct 13, 2025
View reviewed changes

pepijnve force-pushed the issue_882 branch from 4ea9861 to 27958cdCompare October 13, 2025 15:59

apache#882Add support for loading native library from a user specifi…
73c1f47
…ed location

pepijnve force-pushed the issue_882 branch from 27958cd to 73c1f47Compare October 27, 2025 13:06

lidavidm approved these changes Oct 27, 2025
View reviewed changes

lidavidm merged commit ed81e59 into apache:mainOct 27, 2025
23 of 25 checks passed

pepijnve requested review from jbonofre, laurentgo, lidavidm and wgtmac as code owners October 10, 2025 07:57

pepijnve changed the title ~~Add support for loading native library from a user specified location~~GH-882: Add support for loading native library from a user specified locationOct 10, 2025

This comment has been minimized.
Sign in to view

lidavidm added the enhancement PRs that add or improve features. label Oct 10, 2025

github-actionsBot added this to the 18.4.0 milestone Oct 10, 2025

lidavidm approved these changes Oct 13, 2025
View reviewed changes

lidavidm reviewed Oct 13, 2025
View reviewed changes

pepijnve force-pushed the issue_882 branch from 4ea9861 to 27958cdCompare October 13, 2025 15:59

apache#882Add support for loading native library from a user specifi…
73c1f47
…ed location

pepijnve force-pushed the issue_882 branch from 27958cd to 73c1f47Compare October 27, 2025 13:06

lidavidm approved these changes Oct 27, 2025
View reviewed changes

lidavidm merged commit ed81e59 into apache:mainOct 27, 2025
23 of 25 checks passed

pepijnve requested review from jbonofre, laurentgo, lidavidm and wgtmac as code owners October 10, 2025 07:57

pepijnve changed the title ~~Add support for loading native library from a user specified location~~GH-882: Add support for loading native library from a user specified locationOct 10, 2025

This comment has been minimized.
Sign in to view

lidavidm added the enhancement PRs that add or improve features. label Oct 10, 2025

github-actionsBot added this to the 18.4.0 milestone Oct 10, 2025

lidavidm approved these changes Oct 13, 2025
View reviewed changes

lidavidm reviewed Oct 13, 2025
View reviewed changes

pepijnve force-pushed the issue_882 branch from 4ea9861 to 27958cdCompare October 13, 2025 15:59

apache#882Add support for loading native library from a user specifi…
73c1f47
…ed location

pepijnve force-pushed the issue_882 branch from 27958cd to 73c1f47Compare October 27, 2025 13:06

lidavidm approved these changes Oct 27, 2025
View reviewed changes

lidavidm merged commit ed81e59 into apache:mainOct 27, 2025
23 of 25 checks passed

Uh oh!

Conversation

pepijnve commented Oct 10, 2025

What's Changed

Uh oh!

This comment has been minimized.

lidavidm commented Oct 10, 2025

Uh oh!

pepijnve commented Oct 10, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lidavidm commented Oct 10, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lidavidm commented Oct 13, 2025

Uh oh!

lidavidm commented Oct 13, 2025

Uh oh!

lidavidm commented Oct 27, 2025

Uh oh!

lidavidm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

pepijnve commented Oct 10, 2025

What's Changed

Uh oh!

This comment has been minimized.

lidavidm commented Oct 10, 2025

Uh oh!

pepijnve commented Oct 10, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lidavidm commented Oct 10, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lidavidm commented Oct 13, 2025

Uh oh!

lidavidm commented Oct 13, 2025

Uh oh!

lidavidm commented Oct 27, 2025

Uh oh!

lidavidm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

pepijnve commented Oct 10, 2025

What's Changed

Uh oh!

This comment has been minimized.

pepijnve commented Oct 10, 2025•
edited
Loading

pepijnve commented Oct 10, 2025•
edited
Loading

pepijnve commented Oct 10, 2025•
edited
Loading

pepijnve commented Oct 10, 2025•
edited
Loading