Summary
JniType(string)/JniEnvironment.Types.FindClass(string) and the UTF-8 ReadOnlySpan<byte> overloads currently do not behave the same.
The string path first tries raw JNI FindClass() and then falls back to Class.forName(name, true, info.Runtime.ClassLoader). The UTF-8 overload only does the raw FindClass() call.
Why this matters
On Android, raw FindClass() can resolve through a different class loader than the runtime/app loader, or fail in cases where Class.forName() succeeds. This means callers using the UTF-8 API can get different behavior and, in some cases, the wrong Class instance.
A portable repro is that the string overload can resolve Java-style names such as "java.lang.Object", while the UTF-8 overload currently throws instead of taking the same fallback path.
Expected behavior
Both overload families should behave identically.
The UTF-8 path should still use raw FindClass() first for the fast path, but if that fails it should marshal to UTF-16 and go through the same Class.forName(..., info.Runtime.ClassLoader) fallback that the string overload uses today.
Summary
JniType(string)/JniEnvironment.Types.FindClass(string)and the UTF-8ReadOnlySpan<byte>overloads currently do not behave the same.The
stringpath first tries raw JNIFindClass()and then falls back toClass.forName(name, true, info.Runtime.ClassLoader). The UTF-8 overload only does the rawFindClass()call.Why this matters
On Android, raw
FindClass()can resolve through a different class loader than the runtime/app loader, or fail in cases whereClass.forName()succeeds. This means callers using the UTF-8 API can get different behavior and, in some cases, the wrongClassinstance.A portable repro is that the string overload can resolve Java-style names such as
"java.lang.Object", while the UTF-8 overload currently throws instead of taking the same fallback path.Expected behavior
Both overload families should behave identically.
The UTF-8 path should still use raw
FindClass()first for the fast path, but if that fails it should marshal to UTF-16 and go through the sameClass.forName(..., info.Runtime.ClassLoader)fallback that thestringoverload uses today.