Community
Participate
Working Groups
Probably drop using PropertyDescriptor. See case 47955, problem with DateBox. In UiBinder we don't create property is there are more then one setX() methods with different types. However only reason why we have 2 methods setValue(Object) and setValue(Date) is because first comes from HasValue<T> where T==Date in case of DateBox. Second method is implementation of HasValue.setValue(T) method in DateBox itself.
We should understand that these two methods are in reality single method/property with type Date. Also would be good to make it work not only with interfaces, but with classes too. I.e. understand that in SuperClass<T> has methods get/setValue(T) then "SubClass extends SuperClass<String>" practically has methods get/setValue(String), so we should use StringPropertyEditor. Difference with interfaces is that we can not just not analyze interface because we will have implementation of method with correct types; with classes we should propagate actual type argument to methods and may be also to super-super classes. May be OpenJDK provides this for free, but not standard Oracle JDK 6. Even trickier is support for GenericClass<String> directly in Java source which we design. It seems that we can not use single ComponentDescription in this case, because exact type of properties and instances of PropertyEditor-s depend on the exact values of type arguments. So, loading ComponentDescription should depend not only on Class itself, but also on instantiation types arguments. And because standard PropertyDescriptor has just get/set Method-s and returns property type based on "bounds" instead of actual types, it looks that it would be easier to get all possible information from PropertyDescriptor and then never use it again anywhere outside of ReflectionUtils. OMG
Closing. Please reopen if this is still an issue.
