You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@opendal.apache.org by "Xuanwo (via GitHub)" <gi...@apache.org> on 2026/09/13 11:38:44 UTC

[PR] fix(bindings/java): use defining class loader on executor threads [opendal]

Xuanwo opened a new pull request, #8293:
URL: https://github.com/apache/opendal/pull/8293

   # Which issue does this PR close?
   
   Closes #8290.
   
   # Rationale for this change
   
   Native executor threads cannot resolve OpenDAL classes when the Java binding is loaded by an isolated class loader. Completing an async operation then panics while looking up `AsyncRegistry`, leaving the future incomplete.
   
   # What changes are included in this PR?
   
   Capture OpenDAL's defining class loader on the Java caller and retain a JNI global reference in the runtime's thread-start hook. Set each worker's context class loader once after attaching, so jni-rs can resolve both the future registry and result/exception classes. The reference follows the runtime lifetime; the default runtime cache remains weak.
   
   Add subprocess regression coverage for default and explicit executors with OpenDAL absent from the system classpath. It covers async reads/writes, metadata, list entries, NotFound errors, subsequent operations, repeated creation/close, and JVM exit. The caller's context loader also cannot see OpenDAL, ensuring initialization uses the defining loader.
   
   The reporter's unchanged isolated-loader reproduction fails on the base and succeeds with this change, including with release native libraries. Validation ran on macOS; Spring Boot fat-jar packaging and Windows/Linux execution were not separately tested.
   
   # Are there any user-facing changes?
   
   Async operations work when OpenDAL is loaded by an isolated class loader. No public signatures change. Worker threads use OpenDAL's defining loader as their context class loader; callbacks that replace it must restore it before returning, as documented in the Java API.
   
   ## Benchmark
   
   Compared base `dba38bbd479af3005a6d169e9cf7cbf31db3023a` with `936827671231fbc00118f8583f2e3f895f71ee4d`, whose source matches the measured working tree. Both use the Cargo release profile selected by the Java release workflow, with identical dependencies and service features.
   
   macOS arm64, JDK 17.0.20.1, default executor, ordinary application classpath, and the memory service. Five independent JVMs per version, alternating run order, with 10,000 warmup reads/stats followed by three rounds of 10,000 operations each. Values are medians across process-level medians of round means; each operation is awaited and its result checked.
   
   | Workload | Before | After | Latency change |
   |---|---:|---:|---:|
   | Async read of 8 bytes | 16.92 µs | 15.78 µs | −6.8% |
   | Async stat | 23.64 µs | 18.68 µs | −21.0% |
   
   These measurements cover local async/JNI overhead, not end-to-end remote-storage performance. The change adds no per-request class-loader switching.
   
   # Breaking changes
   
   # AI Usage Statement
   
   - Harness: Codex.
   - Model: `gpt-6-astra`.
   - Effort: `high`.
   - Role: Reproduced the issue, implemented the fix and regression tests, ran release benchmarks, and prepared this PR under the author's design and validation review. Platform and packaging validation limits are stated above.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@opendal.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] fix(bindings/java): use defining class loader on executor threads [opendal]

Posted by "Xuanwo (via GitHub)" <gi...@apache.org>.
Xuanwo merged PR #8293:
URL: https://github.com/apache/opendal/pull/8293


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@opendal.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org