fix(java/driver/jni): delete JNI local references

[lidavidm]

Assisted-by: Claude Opus 4.8 noreply@anthropic.com

[Copilot]

Pull request overview

This PR addresses potential JNI local reference table overflows/leaks in the Java ADBC JNI driver by explicitly deleting JNI local references that can otherwise accumulate during long-running native calls or loops.

Changes:

• Delete the jstring local reference in JniStringView’s destructor after releasing UTF chars.
• In statementExecutePartitions, add a null/exception check after NewByteArray and delete the per-iteration jbyteArray local reference after passing it to Java.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[zeroshade]

is there any way to test this and verify?

[lidavidm]

I believe HotSpot/OpenJDK is not affected by this.

https://bugs.openjdk.org/browse/JDK-8297106

In practice, in Hotspot, the actual functionality of EnsureLocalcapacity is a no-op: there is no inherent local ref capacity limit: we create them till we run out of memory. So the Xcheck:jni version of EnsureLocalCapacity is just a way to encourage people to write portable JNI code, in case it runs on a VM that does have a limit.

It appears neither is Android, after 8.0:

https://developer.android.com/ndk/guides/jni-tips

In Android versions prior to Android 8.0, the number of local references is capped at a version-specific limit. Beginning in Android 8.0, Android supports unlimited local references.

So we would need to test a JVM implementation that isn't derived from OpenJDK, that isn't Android; I believe this is very very few implementations.

I can't find any reference to a limit for GraalVM, either. At this point the only other implementation I can think of is CheerpJ, but I don't think we support that in principle in the first place, so...