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)
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
--
Best regards, Sergey.
