Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 348595

Summary: Provide better support for generic properties
Product: z_Archived Reporter: Konstantin Scheglov <Konstantin.Scheglov>
Component: WindowBuilderAssignee: Konstantin Scheglov <Konstantin.Scheglov>
Status: CLOSED INVALID QA Contact:
Severity: enhancement    
Priority: P3 CC: clayberg, wim.jongman
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description Konstantin Scheglov CLA 2011-06-07 11:27:46 EDT 
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.
Comment 1 Konstantin Scheglov CLA 2011-06-07 11:29:20 EDT 
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
Comment 2 Wim Jongman CLA 2021-02-27 12:03:33 EST 
Closing. Please reopen if this is still an issue.