You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When ApiXmlAdjuster attempts to resolve the base type of java.util.ArrayList, there are 2 choices:
[Register("java/util/ArrayList", DoNotGenerateAcw=true)]
public class Android.Runtime.JavaList : Java.Lang.Object { ... }
[Register("java/util/ArrayList", DoNotGenerateAcw=true)]
public class Java.Util.ArrayList : Java.Util.AbstractList { ... }
Because we simply use the "first" type we come across that matches, we are using JavaList instead of ArrayList. This means when we try to resolve overrides for methods, it will not find base methods such as void clear ().
Practically this isn't that big of a deal. This affects code that removes "excess" overrides that we don't need to generate. (ie: we don't need to generate an override if it's the same as the base class's method.) The net result is just that we generate these extra unneeded methods.
Largely this is just an "unspecified" behavior that breaks comparisons with the new Java type resolver.
The text was updated successfully, but these errors were encountered:
jpobst
added
bug
Component does not function as intended
generator
Issues binding a Java library (generator, class-parse, etc.)
labels
Jun 17, 2021
Consider the type:
When
ApiXmlAdjuster
attempts to resolve the base type ofjava.util.ArrayList
, there are 2 choices:Because we simply use the "first" type we come across that matches, we are using
JavaList
instead ofArrayList
. This means when we try to resolve overrides for methods, it will not find base methods such asvoid clear ()
.Practically this isn't that big of a deal. This affects code that removes "excess" overrides that we don't need to generate. (ie: we don't need to generate an override if it's the same as the base class's method.) The net result is just that we generate these extra unneeded methods.
Largely this is just an "unspecified" behavior that breaks comparisons with the new Java type resolver.
The text was updated successfully, but these errors were encountered: