Commit 137214a
committed
Fixity Fix
dotnet/java-interop#1302 fixed the
`Could not determine Java type corresponding to System.Byte[]` crash.
What replaced it was:
Mono.Android.NET_Tests, Java.InteropTests.JnienvTest.NewObjectArrayWithNonJavaType / Release
System.ArgumentException : Could not determine Java type corresponding to System.Type, System.Private.CoreLib, Version=10.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e. Arg_ParamName_Name, type
The deal is that [`JavaNativeTypeManager.ToJniName(Type)`][0]
defaults to using `java/lang/Object` if there is no type mapping.
This is "reasonable" because of the "auto-box into
`Android.Runtime.JavaObject`" behavior, meaning it *is*
possible to create a Java array that "holds" `System.Type` instances.
(Because the Java-side array is actually a `java.lang.Object[]`, each
instance of which is an `Android.Runtime.JavaObject`, which in turn
holds the `System.Type` instance.)
However, this is *not* a semantic that
`JniRuntime.JniTypeManager.GetTypeSignature()` maintains, and thus
this was lost in 1b1f145.
Update `JNIEnv.FindClass(Type)` so that if `.GetTypeSignature()`
can't find the typemapping, default to `java/lang/Object`.
This allows all tests to pass, locally.
[0]: https://github.com/dotnet/java-interop/blob/62635a3ffee4c9ec421eb029b86e61267a544f92/src/Java.Interop.Tools.TypeNameMappings/Java.Interop.Tools.TypeNameMappings/JavaNativeTypeManager.cs#L164-L1681 parent 32e43f0 commit 137214a
1 file changed
+4
-3
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
254 | 254 | | |
255 | 255 | | |
256 | 256 | | |
| 257 | + | |
257 | 258 | | |
258 | 259 | | |
259 | 260 | | |
260 | | - | |
| 261 | + | |
261 | 262 | | |
| 263 | + | |
262 | 264 | | |
263 | 265 | | |
264 | | - | |
| 266 | + | |
265 | 267 | | |
266 | 268 | | |
267 | 269 | | |
268 | 270 | | |
269 | 271 | | |
270 | | - | |
271 | 272 | | |
272 | 273 | | |
273 | 274 | | |
| |||
0 commit comments