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

[Semyon Sadetsky]

On 5/25/2016 9:25 PM, Sergey Bylokhov wrote:
> 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)
Yes, I mistook. It looks like the result is wrong when there is an 
overloaded method with lexicographicaly smaller parameter type name.

--Semyon
>
>
>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>