[Mono.Android] Java.Interop Unification! - #9640
Merged
Merged
Conversation
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Context: https://github.com/xamarin/monodroid/commit/e318861ed8eb20a71852378ddd558409d6b1c234
Context: 130905e
Context: de04316
Context: #9636
In the beginning there was Mono for Android, which had a set of
Mono.Android.dllassemblies (one per supported API level), each of which contained "duplicated" binding logic: each API level had its ownJava.Lang.Object,Android.Runtime.JNIEnv, etc.dotnet/java-interop started, in part, as a way to "split out" the core integration logic, so that it wouldn't need to be duplicated across every assembly. As part of this, it introduced its own core abstractions, notably
Java.Interop.IJavaPeerableandJava.Interop.JavaObject.When dotnet/java-interop was first introduced into Xamarin.Android, with xamarin/monodroid@e318861e, the integration was incomplete. Integration continued with 130905e, allowing unit tests within
Java.Interop-Tests.dllto run within Xamarin.Android and construction of instances of e.g.JavaInt32Array, but one large piece of integration remained:Moving GC bridge code out of
Java.Lang.Object, and instead relying onJava.Interop.JavaObject, turning this:into this:
Why? In part because @jonpryor has wanted to do this for literal years at this point, but also in part because of #9636 and related efforts to use Native AOT, which involves avoiding / bypassing
DllImportAttributeinvocations (for now, everything touched by Native AOT becomes a single.sobinary, which we don't know the name of). Avoiding P/Invoke means embracing and extending existing Java.Interop constructs (e.g. de04316).In addition to altering the base types of
Java.Lang.ObjectandJava.Lang.Throwable:Remove
handleand related fields fromJava.Lang.ObjectandJava.Lang.Throwable.Update
PreserveLists/Mono.Android.xmlso that the removed fields are note preserved.Rename
JNIenvInit.AndroidValueManagertoJNIEnvInit.ValueManager, and change its type toJniRuntime.JniValueManager. This is to help "force" usage ofJnIRuntime.JniValueManagerin more places, as we can't currently useAndroidValueManagerin Native AOT (P/Invokes!).Cleanup: Remove
JNIEnv.Exit()and related code. These were used by the Android Designer, which is no longer supported.Update (
internal) interfaceIJavaObjectExto remove constructs present onIJavaPeerable.Known issues:
Java.Lang.Throwable(IntPtr, JniHandleOwnership)invocation will result in construction of an "extra"java.lang.Throwableinstance on the Java side, which will be immediately discarded. This is because it uses theJavaException(string, Exception)constructor, which implicitly creates a Java peer.We may need dotnet/java-interop changes to better address this.