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

[Semyon Sadetsky]

On 5/26/2016 1:47 PM, Sergey Bylokhov wrote:
> On 26.05.16 9:51, Semyon Sadetsky wrote:
>> Property may be randomly or predictably selected using some algo. But
>> the corresponding PropertyDescriptor should contain the correct getter
>> and setter.
>> We have :
>>     SUPER.setFoo(Long)
>>     SUPER.getFoo()
>>     SUB.setFoo(Long)
>>     SUB.setFoo(Integer)
>>
>> How many Foos may be combined here :
>> 1. Long Foo : SUPER.getFoo() / SUB.setFoo(Long)
>> 2. Integer Foo: null / SUB.setFoo(Integer)
>
> In this case we have 2 properties. The SUPER property have foo=long, 
> which can be checked if you run Introspector on it. The SUB property 
> have foo=int, which can be checked using Introspector and SUPER as 
> stop class. Since this types don't correspond to eachother then the 
> SUB property discarded(it does not mean that we select incorrect 
> method it means that we totally skip the whole incorrect SUB 
> property). This is the case which we are talking from the beginning 
> and which was filed:
> https://bugs.openjdk.java.net/browse/JDK-8157828
Okay, SUB foo=int property is discarded. But why SUB.setFoo(Long) is 
discarded as well? Is it because it is treated as yet another foo=long 
property but on the SUB level?
And why it is not discarded if I change SUB.setFoo(Integer) to 
SUB.setFoo(String) for example? That seems very odd.

And before your fix there was no such behavior. You wrote that it was 
random before the fix, but I ran the test may times and could not get 
the same effect.
So I suppose it was introduced by the fix.

Also there is yet another problem here. The default interface methods 
are totally ignored. This is probably a separate issue.

--Semyon
>
>>
>> In my opinion, the method may return any of this two (also a secondary
>> rank could be used), but not a mixture of them in any circumstances.
>>
>> --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
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>