Fix UTF-8 JniType class lookup fallback

[simonrozsival]

Summary

Make the UTF-8 JniType(ReadOnlySpan<byte>)/FindClass(ReadOnlySpan<byte>) path behave the same as the existing string overloads.

This change:

• keeps the raw FindClass() fast path
• falls back through Class.forName(..., Runtime.ClassLoader) when needed
• uses NewStringUTF() in the UTF-8 fallback path to avoid allocating a managed UTF-16 string first
• adds regression tests so both overload families stay aligned

Fixes #1406.

[Copilot]

Pull request overview

Aligns UTF-8 ReadOnlySpan<byte> class lookup behavior with existing string overload semantics in Java.Interop, ensuring consistent resolution via FindClass() fast path with a Class.forName(..., Runtime.ClassLoader) fallback, and adds regression tests to keep the overload families in sync.

Changes:

• Refactors TryFindClass(string) to delegate fallback logic into a shared helper.
• Adds UTF-8 fallback path using NewStringUTF() to avoid allocating a managed UTF-16 string before calling Class.forName(...).
• Adds tests validating UTF-8 FindClass and JniType constructor fallback parity with the string overloads.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/Java.Interop/Java.Interop/JniEnvironment.Types.cs	Adds shared fallback logic and extends UTF-8 FindClass(ReadOnlySpan<byte>) to match string lookup semantics.
tests/Java.Interop-Tests/Java.Interop/JniTypeUtf8Test.cs	Adds regression tests ensuring UTF-8 overloads behave like the existing string overloads.

[jonathanpeppers]

🤖 PR Review — Fix UTF-8 JniType class lookup fallback

Bug fixed: The ReadOnlySpan<byte> overload of FindClass did not fall back through Class.forName() when JNI FindClass failed — unlike the string overload. This meant Java-style names like "java.lang.Object"u8 would fail for UTF-8 but succeed for strings.

Key changes

Area	What changed
TryLoadClassWithFallback	New shared helper extracts the Class.forName() fallback from the string path so both overloads use it
NewJavaNameFromUtf8	Converts UTF-8 JNI name (/ → .) and calls NewStringUTF to avoid a managed UTF-16 allocation
String overload	Refactored to call TryLoadClassWithFallback instead of inline logic
Tests	Two new tests verify both FindClass and JniType constructor fallback parity

Assessment

✅ Looks good overall. The refactoring correctly preserves the original fallback semantics:

• When Class.forName succeeds → returns class (unchanged)
• When both fail with throwOnError=true → throws pendingException (the original Java exception)
• The new InvalidOperationException is only reached in the edge case where pendingException is null (previously would've been NullReferenceException from throw pendingException! — so this is a bug fix)

✅ NewJavaNameFromUtf8 is well-designed: stackalloc for ≤256 bytes, proper null termination, ExceptionDispatchInfo to preserve stack trace from NewStringUTF failures.

✅ Tests adequately cover the fix by using dot-separated names that force the Class.forName fallback path.

Minor nit

There appears to be trailing whitespace on the throw new InvalidOperationException line in the string path (~line 70 of the diff). Not a functional issue, but doesn't match the rest of the file's style.