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

[Semyon Sadetsky]

With the classes below:

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.

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