-
Notifications
You must be signed in to change notification settings - Fork 55
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Java.Interop.Tools.JavaCallableWrappers] Error on bad IJavaObject (#179
) Context: https://bugzilla.xamarin.com/show_bug.cgi?id=56819 Nothing *prevents* "anybody" from custom implementing `IJavaObject`: class MyBadClass : Android.Runtime.IJavaObject { public IntPtr Handle { get {return IntPtr.Zero;} } public void Dispose () {} } The problem is that the above doesn't actually work: the `IJavaObject.Handle` value contains the JNI Object Reference to pass into JNI. The above code will thus result in always passing `null` into Java code, which could result in a `NullPointerException`, but will always result in *not* doing what was intended. While it is *theoretically* possible to manually implement `IJavaObject`, it's not something *I* would want to contemplate, nor is it for the faint of heart, so long ago we decided to emit a warning if we encounter a type which: 1. Implements `Android.Runtime.IJavaObject`, and 2. Does *not* also inherit `Java.Lang.Object` or `Java.Lang.Throwable`. As such, the above `MyBadClass` would elicit the warning: Type 'MyBadClass' implements Android.Runtime.IJavaObject but does not inherit from Java.Lang.Object. It is not supported. This is all well and good, but (effectively) *nobody* reads warnings, *especially* since our toolchain emits so many warnings that enabling `/warnaserror` is for the truly foolhardy, so *lots* of warnings is, unfortunately, normal. Which brings us to Bug #56819: Could we make this an error? Answer: Of course we can. That said, I have no idea how much existing code this will *break* if we turned it into an error. That might be good and useful, but if there's no way to *disable* the error, existing apps which (appear to) work will no longer build. That's not desirable. Turn `JavaTypeScanner` from a `static` class into a normal class, and add a new `JavaTypeScanner.ErrorOnCustomJavaObject` property which, when true, will cause `JavaTypeScanner` to emit an error instead of a warning when it encounters types such as `MyBadClass`. (I'm turning it into a normal class instead of adding a new `JavaTypeScanner.GetJavaTypes()` overload in case we need to add additional such "control" parameters in the future. Method overloads will otherwise get unwieldy.) `JavaTypeScanner.ErrorOnCustomJavaObject` is all well and good, but how do we *actually* emit a warning vs. an error? The previous `Action<string, object[]> log` delegate doesn't allow distinguishing between warnings and errors (and possible diagnostic messages), so how would we eventually hook this up into xamarin-android's `<GenerateJavaStubs/>` task? Attempt to better handle that question by replacing `Action<string, object[]>` delegates with `Action<TraceLevel, string>` delegates. This allows messages to explicitly specify TraceLevel.Error, TraceLevel.Warning, or TraceLevel.Info (or others!) so that messages can be sanely processed by downstream users. Additionally, add a new `Diagnostic.CreateConsoleLogger()` method which creates an `Action<TraceLevel, string>` which forwards messages to `Console.Error` or `Console.Out`, as appropriate.
- Loading branch information
1 parent
bac28ab
commit ab3c2b2
Showing
7 changed files
with
111 additions
and
42 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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