feat(bindings/java): Speed up the performance of OperatorInputStream

[Xuanwo]

Which issue does this PR close?

Closes #.

Rationale for this change

This PR is used to speed up the performance of OperatorInputStream:

Before:

❯ java -jar target/benchmarks.jar org.apache.opendal.bench.jmh.OperatorReadJmhBenchmark

Benchmark                                       MiB/s
org.apache.opendal.bench.jmh.OperatorReadJmhBenchmark.createInputStream   1468.264
org.apache.opendal.bench.jmh.OperatorReadJmhBenchmark.readRange  44586.656

After:

❯ java -jar target/benchmarks.jar org.apache.opendal.bench.jmh.OperatorReadJmhBenchmark
Benchmark                                       MiB/s
org.apache.opendal.bench.jmh.OperatorReadJmhBenchmark.createInputStream  22430.267
org.apache.opendal.bench.jmh.OperatorReadJmhBenchmark.readRange  48399.451

Still slower than readRange but much faster than before.

What changes are included in this PR?

• Add a basic benchmark framework for opendal java
• Implement int read(byte[] b, int off, int len) for OperatorInputStream

Are there any user-facing changes?

AI Usage Statement

Parts of this PR were drafted with assistance from Codex (with gpt-5.2) and fully reviewed and edited by me. I take full responsibility for all changes.

[Xuanwo]

I found that if we don't change this, the program will hang indefinitely in JMH.

cc @tisonkun what do you think about this change?

[tisonkun]

We may tag @rib here.

Later we can try to migrate to jni-rs 0.22 but there should be some similar issues.

[rib]

A hang from not using _as_daemon implies you have some code that is using JavaVM::destroy() / DestroyJavaVM which is probably unsafe / unsound in any project with RAII types (including global references from the jni crate) that may result in jni usage after the vm is destroyed.

The most likely reason it appears to hang is because DestroyJavaVM will block and wait for (non-daemon) jni threads to exit.

Attaching as daemon threads will avoid that blocking but will almost certainly be completely unsound.

The hang itself indicates that the non-blocking case is unsound because it implies you have non-daemon threads that are associated with the jni crate which has RAII types that may trigger JNI usage after the VM has been destroyed.

The safe fix to avoid the blocking would be to have a mechanism to terminate any jni threads you have (e.g. destroying your tokio runtime + thread pool). Or don't ever try and destroy the VM (this is a very poorly defined operation).

[tisonkun]

From the code itself there is no JavaVM::destroy() explicitly. But perhaps there are some implict calls.

Thanks for your information. I'll try to figure it out.

[tisonkun]

Perhaps read as much as len as possible?

Currently, it reads what remaining in the bytes buffer or read at most once.

[tisonkun]

Weird while here.

Perhaps loop over len > 0 and try to copy from bytes until len fulfilled or end.

[tisonkun]

LGTM.

The read impl can be improved later.

The attach_current_thread_as_daemon should be resolved as it's not recommended. But we need some help from @rib and perhaps include it when testing out jni-rs 0.22.