Fix #97: Allow custom native library directory via h3.native.dir - #209
Fix #97: Allow custom native library directory via h3.native.dir#209dyrpsf wants to merge 4 commits into
Conversation
Coverage Report for CI Build 665Warning Build has drifted: This PR's base is out of sync with its target branch, so coverage data may include unrelated changes. Coverage decreased (-0.6%) to 96.387%Details
Uncovered Changes
Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
|
Just pushed a quick update! The initial CI run failed on the I ran |
|
Hi team, just pushed a quick update! I've added a unit test for the To ensure the test is robust across different CI runners and local machines, it dynamically detects the OS to handle POSIX permissions properly, and it uses reflection to test the private extraction method without interfering with the singleton caching used by the rest of the test suite. The pipeline should be all green now. Let me know if anything else is needed before merging! |
Description
Fixes #97.
Currently,
H3CoreLoaderalways extracts the native library (.so/.dll/.dylib) to the operating system's default temporary directory (e.g.,/tmp/). As reported in #97, this causesUnsatisfiedLinkErrors in distributed environments like Apache Flink or Spark, where worker nodes frequently clean up or isolate the/tmpdirectory between task restorations.This PR introduces a safe escape hatch for these environments. It updates
createTempLibraryFileto check for a Java system property namedh3.native.dir.java.io.tmpdirbehavior.Testing
Local Java compilation succeeds. Relying on the CI pipeline to compile the native binaries and execute the test suite to ensure the extraction logic functions correctly across OS platforms.