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

[Semyon Sadetsky]

On 5/25/2016 5:02 PM, Sergey Bylokhov wrote:
> On 25.05.16 15:06, Semyon Sadetsky wrote:
>> 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) {}
>> }
>>
>> For Sub class the Introspector gives:
>>
>> type: class java.lang.Long
>> getter: public java.lang.Long Super.getFoo()
>> setter: public void Super.setFoo(java.lang.Long)
>>
>> I would expect to see "public void *Sub*.setFoo(java.lang.Long)" as a
>> setter.
>
> Why? the super class have foo property and the Sub class have foo 
> property. For Super the type is Long, but for Sub class the type is 
> unspecified(it can be Long or Integer).
> As described above when you run the Introspector on Sub.class and use 
> Super.class as a stop class then you will see that we select 
> foo=Integer, and this type is not compatible with Long from the 
> parent, so it is discarded.
>
> 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.
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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>