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

[Sergey Bylokhov]

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).


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