[generator] Qualify Java.Lang.Object.Handle references #38
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.
Android N Preview 2 adds some methods named
handle(), such asjava.util.concurrent.CompletableFuture.handle(). This clashes withthe Java.Lang.Object.Handle property, resulting in C# compiler errors
within the generated binding code:
There are two possible fixes:
Handle, and rename any occurrences to somethingelse, such as
InvokeHandle.Java.Lang.Object.Handleproperty reference.(1) is kinda ugly.
(2) is possible by using a cast: instead of
value.Handle, use e.g.((Java.Lang.Object) value).Handle, which causes the compiler to usethe intended member, and not whatever may be hiding it in the current
scope.
(2) results in an arguably nicer API -- maybe? -- as the bound API
more closely mirrors the Java API.
(2) also results in uglier binding code. However, who reads it?
Note: Why cast to e.g. Java.Lang.Object and not IJavaObject? To avoid
virtual calls.
((Java.Lang.Object)value).Handleresults in a directinvocation of the Object.get_Handle() method, avoiding a virtual call.
Casting to IJavaObject would result in a virtual interface method
invocation, causing additional runtime overhead to lookup the value.