Generate Threshold{Class,Type} properties for all classes #154
Conversation
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 will need to be updated to account for PR #153, which was just merged. :-( |
If a class derives from `Java.Lang.Object` it should have the two properties mentioned above generated, so that it is possible to find methods in the correct instance of Java class instance that is wrapped by our managed class. Generator used to decide whether or not to generate these properties based on the presence of class members (fields, constructors, methods and properties) or whether the class is an annotation in the API description file. However there exist a number of classes (for instance `Inet4Address`) which don't have any of the members present and yet they should have the Threshold* properties generated for the reasons described above. The `HasClassHandle` property which was used to determine whether the class should get these properties (among a handful of other members) doesn't serve its purpose correctly leading to corner cases when the `Threshold*` properties are missing and causing runtime bugs (e.g. calling `GetAddress()` on an instance of `Inet4Address` returns `null` even though the underlying Java class has the information - the call never reaches `Inet4Address` instance and thus returns nothing). Replacing `HasClassHandle` with a simple check for whether the class in question derives from `Java.Lang.Object` is the correct fix that ensures the missing properties are generated. Fixe https://bugzilla.xamarin.com/show_bug.cgi?id=56537
jonpryor
pushed a commit
to jonpryor/java.interop
that referenced
this pull request
Jun 20, 2017
…dotnet#154) Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=56537 If a class derives from `Java.Lang.Object` it should have the two properties mentioned above generated, so that it is possible to find methods in the correct instance of Java class instance that is wrapped by our managed class. Generator used to decide whether or not to generate these properties based on the presence of class members (fields, constructors, methods and properties) or whether the class is an annotation in the API description file. However there exist a number of classes (for instance `Inet4Address`) which don't have any of the members present and yet they should have the Threshold* properties generated for the reasons described above. The `HasClassHandle` property which was used to determine whether the class should get these properties (among a handful of other members) doesn't serve its purpose correctly leading to corner cases when the `Threshold*` properties are missing and causing runtime bugs (e.g. calling `GetAddress()` on an instance of `Inet4Address` returns `null` even though the underlying Java class has the information - the call never reaches `Inet4Address` instance and thus returns nothing). Replacing `HasClassHandle` with a simple check for whether the class in question derives from `Java.Lang.Object` is the correct fix that ensures the missing properties are generated.
jonpryor
added a commit
that referenced
this pull request
Jun 20, 2017
…#154) (#160) Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=56537 If a class derives from `Java.Lang.Object` it should have the two properties mentioned above generated, so that it is possible to find methods in the correct instance of Java class instance that is wrapped by our managed class. Generator used to decide whether or not to generate these properties based on the presence of class members (fields, constructors, methods and properties) or whether the class is an annotation in the API description file. However there exist a number of classes (for instance `Inet4Address`) which don't have any of the members present and yet they should have the Threshold* properties generated for the reasons described above. The `HasClassHandle` property which was used to determine whether the class should get these properties (among a handful of other members) doesn't serve its purpose correctly leading to corner cases when the `Threshold*` properties are missing and causing runtime bugs (e.g. calling `GetAddress()` on an instance of `Inet4Address` returns `null` even though the underlying Java class has the information - the call never reaches `Inet4Address` instance and thus returns nothing). Replacing `HasClassHandle` with a simple check for whether the class in question derives from `Java.Lang.Object` is the correct fix that ensures the missing properties are generated.
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.
If a class derives from
Java.Lang.Objectit should have the two propertiesmentioned above generated, so that it is possible to find methods in the correct
instance of Java class instance that is wrapped by our managed class.
Generator used to decide whether or not to generate these properties based on
the presence of class members (fields, constructors, methods and properties) or
whether the class is an annotation in the API description file.
However there exist a number of classes (for instance
Inet4Address) which don'thave any of the members present and yet they should have the Threshold*
properties generated for the reasons described above.
The
HasClassHandleproperty which was used to determine whether the class shouldget these properties (among a handful of other members) doesn't serve its
purpose correctly leading to corner cases when the
Threshold*properties aremissing and causing runtime bugs (e.g. calling
GetAddress()on an instance ofInet4Addressreturnsnulleven though the underlying Java class has theinformation - the call never reaches
Inet4Addressinstance and thus returnsnothing).
Replacing
HasClassHandlewith a simple check for whether the class in questionderives from
Java.Lang.Objectis the correct fix that ensures the missingproperties are generated.
Fixe https://bugzilla.xamarin.com/show_bug.cgi?id=56537