You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Java.Interop] Generic Type Definitions are allowed (#1336)
Context: dotnet/android#9913
Context: dotnet/android@de49d96Fixes: #1324dotnet/android#9913 updated `JNIEnv.GetJniName(Type)` to use
`JniRuntime.JniTypeManager.GetTypeSignature(Type)`.
It promptly failed on CI:
E NUnit : : System.NotSupportedException : 'Java.InteropTests.GenericHolder`1[T]' contains a generic type definition. This is not supported.
E NUnit : at Java.Interop.JniRuntime.JniTypeManager.GetTypeSignature(Type )
E NUnit : at Android.Runtime.JNIEnv.GetJniName(Type )
E NUnit : at Java.Interop.TypeManager.RegisterType(String , Type )
E NUnit : at Android.Runtime.JNIEnvInit.RegisterJniNatives(IntPtr , Int32 , IntPtr , IntPtr , Int32 )
E NUnit : at Java.Interop.JniEnvironment.Object.AllocObject(JniObjectReference )
E NUnit : at Java.Interop.JniType.AllocObject()
E NUnit : at Java.Interop.JniPeerMembers.JniInstanceMethods.StartCreateInstance(String , Type , JniArgumentValue* )
E NUnit : at Java.Lang.Object..ctor()
E NUnit : at Java.InteropTests.GenericHolder`1[[System.Int32, System.Private.CoreLib, Version=10.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]..ctor()
E NUnit : at Java.InteropTests.JnienvTest.NewClosedGenericTypeWorks()
E NUnit : at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
E NUnit : at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object , BindingFlags )
because of this check within
`JniRuntime.JniTypeManager.GetTypeSignature()`:
if (type.ContainsGenericParameters)
throw new NotSupportedException ($"'{type}' contains a generic type definition. This is not supported.");
Why is `type.ContainsGenericParameters` true?
`type.ContainsGenericParameters` is true because XAJavaInterop1-style
Java Callable Wrappers contain an Assembly Qualified Type Name, and
if the underlying type is generic, then the assembly qualified type
name mentions the type definition. Consider:
// C#
class GenericHolder<T> : Java.Lang.Object {
}
results in this Java Callable Wrapper snippet:
// Java
public /* partial */ class GenericHolder_1
{
public static final String __md_methods;
static {
__md_methods = "";
mono.android.Runtime.register ("Java.InteropTests.GenericHolder`1, Mono.Android-Tests", GenericHolder_1.class, __md_methods);
}
}
Note ``Java.InteropTests.GenericHolder`1, Mono.Android-Tests``:
``Type.GetType("Java.InteropTests.GenericHolder`1, Mono.Android-Tests")``
results in a type definition, in which `type.ContainsGenericParameters`
is true.
*Is this a problem*? No, it is not a problem *in type registration*,
as this has worked in dotnet/android for many years at this point.
Is this a problem *elsewhere*? Yes:
1. Instances of `GenericHolder_1` cannot be created *from Java*,
because Java doesn't know what type parameters to provide,
because of type erasure.
2. `[JavaCallable]` methods on generic types also cannot work,
as only *one* method can be registered, while semantically a
generic method is *N* methods (per type).
Update `JniRuntime.JniTypeManager.GetTypeSignature()` to no longer
check for `type.ContainsGenericParameters`.
Update `JniTypeManagerTests` to assert that constructing instances
from Java results in an exception.
A "funny" thing happened when adding that test: it didn't assert!
There are two reasons for this. The first is that the Java Callable
Wrapper for `Java.InteropTests.GenericHolder<T>` *did not* have a
Java constructor! Without a constructor, it had the default
constructor, which has no such verification check.
The cause of the missing constructor is that
`Java.Interop.Tools.JavaCallableWrappers` needs to know the JNI
signature of the constructor to generate, and the `JavaObject`
default constructor didn't have `[JniConstructorSignature]`.
Update the `JavaObject` default constructor appropriately:
partial class JavaObject {
[JniConstructorSignature ("()V")]
public JavaObject () …
}
This causes the Java Callable Wrapper for `GenericHolder<T>` to have
the desired constructor which calls `ManagedPeer.construct()`,
which in turn is a prerequisite for throwing `NotSupportedException`.
The second issue is that the `CannotCreateGenericHolderFromJava()`
test *must* use `JNIEnv::AllocObject()` +
`JNIEnv::CallNonvirtualVoidMethod()` to construct the instance,
***not*** `JNIEnv::NewObject()`, because we special-case
`JNIEnv::NewObject()`; see also commit 1c99956.
0 commit comments