[Java.Interop] Convert dot-separated class names before calling FindClass#1409
Merged
jonathanpeppers merged 1 commit intomainfrom Apr 20, 2026
Merged
[Java.Interop] Convert dot-separated class names before calling FindClass#1409jonathanpeppers merged 1 commit intomainfrom
jonathanpeppers merged 1 commit intomainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Updates JniEnvironment.Types.FindClass to pre-normalize dot-separated Java class names into JNI slash form before invoking raw FindClass, preventing ART CheckJNI from aborting the process before the managed fallback path can run.
Changes:
- Normalize
java.lang.Foo→java/lang/Foobefore the rawFindClasscall in thestringoverload. - Normalize UTF-8 class name spans (
ReadOnlySpan<byte>) by converting.→/into a null-terminated buffer before callingJniNativeMethods.FindClass.
simonrozsival
force-pushed
the
fix-checkjni-findclass-abort
branch
2 times, most recently
from
3396167 to
5c04fb2
Compare
…lass On Android userdebug emulators with CheckJNI enabled, ART validates class name format in FindClass at the native level. Passing a dot-separated name (e.g. "java.lang.Object") causes SIGABRT before the managed Class.forName() fallback can execute. Fix by converting '.' to '/' in the class name before calling raw FindClass, so CheckJNI always sees valid JNI-format names. The Class.forName() fallback still handles classes not findable by FindClass (e.g. custom class loaders). Fixes: dotnet/android#11157 (comment) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
simonrozsival
force-pushed
the
fix-checkjni-findclass-abort
branch
from
5c04fb2 to
56045a8
Compare
simonrozsival
added
the
copilot
jonathanpeppers
approved these changes
Apr 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On Android
userdebugemulators with CheckJNI enabled, ART validates class name format inFindClassat the native level. Passing a dot-separated name (e.g."java.lang.Object") causesSIGABRTbefore the managedClass.forName()fallback can execute.This was introduced in #1407 — the fallback logic works correctly, but the raw
FindClassJNI call fires first with the invalid name format, and CheckJNI kills the process before the exception-based fallback path runs.Fix
Convert
.to/in the class name before calling rawFindClass, so CheckJNI always sees valid JNI-format names (java/lang/Object). TheClass.forName()fallback remains unchanged and still handles classes not findable byFindClass(e.g. custom class loaders).Changes
TryFindClass(string, bool)):classname.Replace('.', '/')beforeTryRawFindClassTryFindClass(ReadOnlySpan<byte>, bool)):stackalloccopy with.→/conversion beforeJniNativeMethods.FindClassFixes: dotnet/android#11157 (comment)