-
Notifications
You must be signed in to change notification settings - Fork 564
[Mono.Android] Define JavaCollection before ICollection #741
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
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
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=58303 Background: It is possible for a Java type to have "aliasing bindings": two or more managed types which claim to bind the same Java type: // C# namespace Android.Runtime { [Register ("java/util/HashMap", DoNotRegisterAcw=true)] partial class JavaDictionary { } } namespace Java.Util { [Register ("java/util/HashMap", DoNotRegisterAcw=true)] partial class HashMap { } } These can't be realistically forbidden. Enter a new-to-bind Java type: // Java public class Bxc58383 extends java.util.HashMap implements java.util.Map { } In order to bind the above `Bxc58383` type, `generator` needs to determine the appropriate binding type to use for `java.util.HashMap`. `generator`'s approach to supporting aliasing types is (largely) to ignore the problem (almost) entirely: There Can Be Only One™ mapping from a Java type to a managed type, so `generator` needs to pick one. It does so by using the *last* definition encountered in the assembly. Consequently, for the above set of C# declarations, when `generator` needs to find the managed type which binds `java.util.HashMap`, `Java.Util.HashMap` will be chosen, as it is the last declared type. Unfortunately, "real life" is a bit more complicated: `Mono.Android.dll` is made up of *thousands* of files, and the order of types within an assembly is a compiler implementation detail. As such...the current `Mono.Android.dll` has `JavaDictionary` defined *after* `HashMap`: # output truncated for relevance $ monodis --typedef bin/Debug/lib/xamarin.android/xbuild-frameworks/MonoAndroid/v7.1/Mono.Android.dll | grep 'Dictionary\|HashMap' 1270: Java.Util.Dictionary (flist=12611, mlist=29569, flags=0x100081, extends=0x20b8) 1287: Java.Util.HashMap (flist=12662, mlist=29806, flags=0x100001, extends=0x1388) 3992: Android.Runtime.JavaDictionary (flist=32135, mlist=85344, flags=0x100001, extends=0x20b8) Because `JavaDictionary` is defined *after* `HashMap`, and both of those types have `[Register]` attributes which declare that they bind the *same* Java type, the result is that the binding of `Bxc58383` is horrifically broken: // C# partial class Bxc58383 : global::Android.Runtime.JavaDictionary, global::Java.Util.IMap { } Unfortunately, `JavaDictionary` doesn't itself implement `IMap`, so: error CS0535: 'Bxc58383' does not implement interface member 'IMap.ContainsKey(Object)' along with 10 other related errors. Update the `src/Mono.Android` build process so that `JavaDictionary` and related types will be defined within `Mono.Android.dll` *before* all the generated types. This allows `HashMap` to be defined last, allowing `Bxc58383` to be bound without error: # output truncated $ monodis --typedef bin/Debug/lib/xamarin.android/xbuild-frameworks/MonoAndroid/v7.1/Mono.Android.dll | grep 'Dictionary\|HashMap' 3703: Android.Runtime.JavaDictionary (flist=34089, mlist=78134, flags=0x100001, extends=0x4e08) 4170: Java.Util.Dictionary (flist=39685, mlist=91737, flags=0x100081, extends=0x4e08) 4187: Java.Util.HashMap (flist=39736, mlist=91974, flags=0x100001, extends=0x40d8)
jonpryor
added a commit
that referenced
this pull request
Aug 11, 2017
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=58303 Background: It is possible for a Java type to have "aliasing bindings": two or more managed types which claim to bind the same Java type: // C# namespace Android.Runtime { [Register ("java/util/HashMap", DoNotRegisterAcw=true)] partial class JavaDictionary { } } namespace Java.Util { [Register ("java/util/HashMap", DoNotRegisterAcw=true)] partial class HashMap { } } These can't be realistically forbidden. Enter a new-to-bind Java type: // Java public class Bxc58383 extends java.util.HashMap implements java.util.Map { } In order to bind the above `Bxc58383` type, `generator` needs to determine the appropriate binding type to use for `java.util.HashMap`. `generator`'s approach to supporting aliasing types is (largely) to ignore the problem (almost) entirely: There Can Be Only One™ mapping from a Java type to a managed type, so `generator` needs to pick one. It does so by using the *last* definition encountered in the assembly. Consequently, for the above set of C# declarations, when `generator` needs to find the managed type which binds `java.util.HashMap`, `Java.Util.HashMap` will be chosen, as it is the last declared type. Unfortunately, "real life" is a bit more complicated: `Mono.Android.dll` is made up of *thousands* of files, and the order of types within an assembly is a compiler implementation detail. As such...the current `Mono.Android.dll` has `JavaDictionary` defined *after* `HashMap`: # output truncated for relevance $ monodis --typedef bin/Debug/lib/xamarin.android/xbuild-frameworks/MonoAndroid/v7.1/Mono.Android.dll | grep 'Dictionary\|HashMap' 1270: Java.Util.Dictionary (flist=12611, mlist=29569, flags=0x100081, extends=0x20b8) 1287: Java.Util.HashMap (flist=12662, mlist=29806, flags=0x100001, extends=0x1388) 3992: Android.Runtime.JavaDictionary (flist=32135, mlist=85344, flags=0x100001, extends=0x20b8) Because `JavaDictionary` is defined *after* `HashMap`, and both of those types have `[Register]` attributes which declare that they bind the *same* Java type, the result is that the binding of `Bxc58383` is horrifically broken: // C# partial class Bxc58383 : global::Android.Runtime.JavaDictionary, global::Java.Util.IMap { } Unfortunately, `JavaDictionary` doesn't itself implement `IMap`, so: error CS0535: 'Bxc58383' does not implement interface member 'IMap.ContainsKey(Object)' along with 10 other related errors. Update the `src/Mono.Android` build process so that `JavaDictionary` and related types will be defined within `Mono.Android.dll` *before* all the generated types. This allows `HashMap` to be defined last, allowing `Bxc58383` to be bound without error: # output truncated $ monodis --typedef bin/Debug/lib/xamarin.android/xbuild-frameworks/MonoAndroid/v7.1/Mono.Android.dll | grep 'Dictionary\|HashMap' 3703: Android.Runtime.JavaDictionary (flist=34089, mlist=78134, flags=0x100001, extends=0x4e08) 4170: Java.Util.Dictionary (flist=39685, mlist=91737, flags=0x100081, extends=0x4e08) 4187: Java.Util.HashMap (flist=39736, mlist=91974, flags=0x100001, extends=0x40d8)
|
@jonpryor this issue seems to be reintroduced some time ago. |
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Oct 20, 2020
Fixes: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1230070 Changes: dotnet/java-interop@b991bb8...da74abd * dotnet/java-interop@da74abd2: Bump to mono/LineEditor@3fa0c2eb (dotnet#740) * dotnet/java-interop@5fe912ad: Bump to xamarin/xamarin-android-tools/main@26d65d9 (dotnet#741) * dotnet/java-interop@9c73dbff: [generator] Output correct formatting for binding warnings (dotnet#737) Update `create-installers.targets` so that `LineEditor.pdb` is included in the macOS `.pkg` and Windows `.vsix` installers.
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Oct 20, 2020
Fixes: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1230070 Changes: dotnet/java-interop@b991bb8...da74abd * dotnet/java-interop@da74abd2: Bump to mono/LineEditor@3fa0c2eb (dotnet#740) * dotnet/java-interop@5fe912ad: Bump to xamarin/xamarin-android-tools/main@26d65d9 (dotnet#741) * dotnet/java-interop@9c73dbff: [generator] Output correct formatting for binding warnings (dotnet#737) Update `create-installers.targets` so that `LineEditor.pdb` is included in the macOS `.pkg` and Windows `.vsix` installers.
jonpryor
added a commit
that referenced
this pull request
Oct 21, 2020
Fixes: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1230070 Changes: dotnet/java-interop@b991bb8...da74abd * dotnet/java-interop@da74abd2: Bump to mono/LineEditor@3fa0c2eb (#740) * dotnet/java-interop@5fe912ad: Bump to xamarin/xamarin-android-tools/main@26d65d9 (#741) * dotnet/java-interop@9c73dbff: [generator] Output correct formatting for binding warnings (#737) Update `create-installers.targets` so that `LineEditor.pdb` is included in the macOS `.pkg` and Windows `.vsix` installers.
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.
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=58303
Background: It is possible for a Java type to have
"aliasing bindings": two or more managed types which claim to bind
the same Java type:
These can't be realistically forbidden.
Enter a new-to-bind Java type:
In order to bind the above
Bxc58383type,generatorneeds todetermine the appropriate binding type to use for
java.util.HashMap.generator's approach to supporting aliasing types is (largely) toignore the problem (almost) entirely: There Can Be Only One™ mapping
from a Java type to a managed type, so
generatorneeds to pick one.It does so by using the last definition encountered in the assembly.
Consequently, for the above set of C# declarations, when
generatorneeds to find the managed type which binds
java.util.HashMap,Java.Util.HashMapwill be chosen, as it is the last declared type.Unfortunately, "real life" is a bit more complicated:
Mono.Android.dllis made up of thousands of files, and the orderof types within an assembly is a compiler implementation detail.
As such...the current
Mono.Android.dllhasJavaDictionarydefinedafter
HashMap:Because
JavaDictionaryis defined afterHashMap, and both ofthose types have
[Register]attributes which declare that they bindthe same Java type, the result is that the binding of
Bxc58383ishorrifically broken:
Unfortunately,
JavaDictionarydoesn't itself implementIMap, so:along with 10 other related errors.
Update the
src/Mono.Androidbuild process so thatJavaDictionaryand related types will be defined within
Mono.Android.dllbeforeall the generated types. This allows
HashMapto be defined last,allowing
Bxc58383to be bound without error: