<Beans Dev> [9] Review Request: 8156043 Unstable behavior of PropertyDescriptor's getWriteMethod() in case of overloaded setters

[Sergey Bylokhov]

On 25.05.16 21:17, Semyon Sadetsky wrote:
>> If the setFor(Integer) will be removed, then we will select the Long
>> as more specific type(from list of Object,Number,Long).
> setFor(Integer) doesn't matter. If one leave only setFoo(Long i) in the
> Sub, the result will be the same.

Note sure, can you double check that result is the same?:
public final class TestMethodOrderDependence {
     class Super  {
         public void setFoo(Long i) {}
         public Long getFoo() {return null;}
     }
     class Sub extends Super {
         public void setFoo(Long i) {}
         //public void setFoo(Integer i) {}
         public void setFoo(Number i) {}
         public void setFoo(Object i) {}
     }

     public static void main(final String[] args) throws Exception {
         final BeanInfo beanInfo = Introspector.getBeanInfo(Sub.class);
         final PropertyDescriptor[] pds = beanInfo.getPropertyDescriptors();
         for (final PropertyDescriptor pd : pds) {
             System.err.println("pd = " + pd);
         }
     }
}
======
And the output is:
pd = java.beans.PropertyDescriptor[name=foo; values={expert=false; 
visualUpdate=false; hidden=false; required=false}; propertyType=class 
java.lang.Long;
readMethod=public java.lang.Long TestMethodOrderDependence$Super.getFoo();
writeMethod=public void 
TestMethodOrderDependence$Sub.setFoo(java.lang.Long)]

Note writeMethod = Sub.setFoo(java.lang.Long)


> In my understanding, if I override the setter I should get the
> over-ridden method for the top level class introspection. Otherwise I do
> not understand for what such introspector can be used:
>
> I have some object which property I want to set, but using the
> introspector for that I'm calling a wrong method which breaks the
> inheritance and so corrupts the object state.
>
> And moreover, if I reverse the situation and override the getter in Sub
> instead of setter :
>
> class Super {
>     public void setFoo(Long i) {}
>     public Long getFoo() {return null;}
> }
> class Sub extends Super {
>     public Long getFoo() {return null;}
> }
>
> the introspector returns the over-ridden getter method for the property :
>
> type: class java.lang.Long
> getter: public java.lang.Long Sub.getFoo()
> setter: public void Super.setFoo(java.lang.Long)
>
> This looks inconsistent.
>
> --Semyon
>>
>>
>>> On 5/25/2016 2:14 PM, Sergey Bylokhov wrote:
>>>> On 25.05.16 11:38, Semyon Sadetsky wrote:
>>>>>> In this case the type of foo property will be Enum, before and after
>>>>>> the fix. But the write method will be found only if this method is
>>>>>> added to Sub, in other case the write method is recognized only if we
>>>>>> remove all duplicates of set(xxx). Not sure is it intended
>>>>>> behavior in
>>>>>> jdk9 to skip such writers or not. I will file CR for that.
>>>>> That maybe an another issue.
>>>>
>>>> I dig to the history and found that it was done intentionally when
>>>> JavaBean jep was implemented. but I filed
>>>> https://bugs.openjdk.java.net/browse/JDK-8157828 for additional
>>>> investigation.
>>>>
>>>>> But the current fix need to be checked by
>>>>> the scenario when there are several getters (over-ridden with the
>>>>> return
>>>>> type substitutability) in addition to the setters.
>>>>
>>>> Tescase is updated, the case: getE + multiple setE is added:
>>>> http://cr.openjdk.java.net/~serb/8156043/webrev.01/
>>>>
>>>>>>> On 5/17/2016 3:20 PM, Sergey Bylokhov wrote:
>>>>>>>> Hello.
>>>>>>>> Please review the fix for jdk9.
>>>>>>>>
>>>>>>>> We have a number of bugs which state that our JavaBeans randomly
>>>>>>>> does
>>>>>>>> not work, examples: JDK-6807471[1] , JDK-6788525[2], the reason is
>>>>>>>> that the order of methods from Class.getMethods() is not specified.
>>>>>>>> So I propose to fix this bug totally and sort the methods in some
>>>>>>>> order. Note that the resulted list is cached, and we sort the list
>>>>>>>> only the once.
>>>>>>>> The code partly was copied from com.sun.jmx.mbeanserver.MethodOrder
>>>>>>>> [3], but the parameters check and the order for return values were
>>>>>>>> changed. After this fix our bugs(if any) can be easily reproduced.
>>>>>>>>
>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-6807471
>>>>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-6788525
>>>>>>>> [3]
>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/fb38b0925915/src/java.management/share/classes/com/sun/jmx/mbeanserver/MBeanAnalyzer.java
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156043
>>>>>>>> Webrev can be found at:
>>>>>>>> http://cr.openjdk.java.net/~serb/8156043/webrev.00
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.