Proof of Concept: Map Java object to single best managed type and ignore requested targetType

[jtschuster]

This is a proof of concept for using the TypeMap API from .NET 10 as the source of .NET - Java type mapping. The TypeMap API only allows for a one-to-one relationship between .NET and Java types. To test the viability of it, this branch removes all conditional logic in mapping a Java object to a .NET type, and follows the algorithm in Android's NativeAOT TypeMappingStep to find the single best type for the Java class, and creates an instance of that type. I didn't find any cases where this fails in tests locally.

[jtschuster]

cc @jonathanpeppers @simonrozsival

[jonpryor]

The PR summary says:

Map Java object to single best managed type and ignore requested targetType.

This is doomed, for two reasons:

1. "Aliasing" is A Thing; e.g. see dotnet/android@b11471b.

   For example, Mono.Android.dll contains three "binding aliases"
   for java.util.ArrayList:

   • Android.Runtime.JavaList
   • Android.Runtime.JavaList<T>
   • Java.Util.ArrayList

   If there is only one best mapping, something is going to break when dealing with the above.

   Or dotnet/android@f03662c:

   Consider java.lang.Object, which is bound as:

   • Java.Lang.Object, Mono.Android
   • Java.Interop.JavaObject, Java.Interop
   • and also several other unit test types as "aliases" (b11471b)

2. The targetType parameter within JniRuntime.JniValueManager.CreatePeer() is how the Java-side type hierarchy is navigated, e.g. to move across implemented Java-side interfaces. See also the .TryJavaCast<TResult>() and .JavaAs<TResult>() extension methods in 7a058c0:

   java-interop/src/Java.Interop/Java.Interop/JavaPeerableExtensions.cs

   Lines 45 to 48 in 02bceb0

   	return JniEnvironment.Runtime.ValueManager.CreatePeer (
   	ref r, JniObjectReferenceOptions.Copy,
   	targetType: typeof (TResult))
   	as TResult;

You cannot "ignore" the targetType parameter.