RFR: 8347826: Introspector shows wrong method list after 8071693 [v4]

[Roman Marchenko]

On Thu, 13 Feb 2025 18:25:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> It was implemented in a way to minimize the difference between different 'stopClasses' for the same object. In the example above, the next call will produce the same properties:
>>> ...
>>> Thus, the methods of the current class have some priority over those of the parent class.
>>> But if the same class has multiple setFoo(xxx) methods, the behavior will be undefined/unspecified.
>> 
>> Currently, I see from `PropertyInfo` implementation that methods are just sorted by argument's type name if arguments are not assignable from each other. So, in case `Long` vs `Number`, `Long` will be chosen (`isAssignable()` check works); in case `Float` vs `Integer`, `Float` will be chosen (sorted by type name).
>> 
>> I'm still wondering if there's  any specification (tests?) describing this. At the time it looks like the current implementation is the only doc.
>> 
>> If no docs, could you review the test cases below, please? Is it correct, or redundant, or incomplete? I will add them to the test when OK. 
>> 
>> 
>> Case 1:
>>     public interface A {
>>         default public void setParentFoo(Integer num) {
>>         }
>>         default public void setFoo(Integer num) {
>>         }
>>     }
>> 
>>     public class D implements A {
>>         public void setFoo(Number num) {
>>         }
>>         public void setLocalFoo(Long num) {
>>         }
>>         public void setLocalFoo(Float num) {
>>         }
>>     }
>> 
>> Expecting:
>> 
>> --- properties
>> public void Test$D.setFoo(java.lang.Number)
>> public void Test$D.setLocalFoo(java.lang.Float)
>> public default void Test$A.setParentFoo(java.lang.Integer)
>> --- methods
>> public void Test$D.setFoo(java.lang.Number)
>> public void Test$D.setLocalFoo(java.lang.Float)
>> public default void Test$A.setFoo(java.lang.Integer)
>> public void Test$D.setLocalFoo(java.lang.Long)
>> public default void Test$A.setParentFoo(java.lang.Integer)
>> 
>> 
>> Case 2:
>>     public class AC {
>>         public void setParentFoo(Integer num) {
>>         }
>>         public void setFoo(Integer num) {
>>         }
>>     }
>> 
>>     public class DC extends AC {
>>         public void setFoo(Number num) {
>>         }
>>         public void setLocalFoo(Long num) {
>>         }
>>         public void setLocalFoo(Float num) {
>>         }
>>     }
>> 
>> Expecting:
>> 
>> --- properties
>> public void Test$DC.setFoo(java.lang.Number)
>> public void Test$DC.setLocalFoo(java.lang.Float)
>> public void Test$AC.setParentFoo(java.lang.Integer)
>> --- methods
>> public void Test$DC.setFoo(java.lang.N...
>
>> > It was implemented in a way to minimize the difference between different 'stopClasses' for the same object. In the example above, the next call will produce the same properties:
>> > ...
>> > Thus, the methods of the current class have some priority over those of the parent class.
>> > But if the same class has multiple setFoo(xxx) methods, the behavior will be undefined/unspecified.
>> 
>> Currently, I see from `PropertyInfo` implementation that methods are just sorted by argument's type name if arguments are not assignable from each other. So, in case `Long` vs `Number`, `Long` will be chosen (`isAssignable()` check works); in case `Float` vs `Integer`, `Float` will be chosen (sorted by type name).
> 
> There is "test/jdk/java/beans/Introspector/TestMethodOrderDependence.java" which was added to prevent accidental change in the implementation, but part of the behavior is undefined/unspecified.
> 
>>If no docs, could you review the test cases below, please? Is it correct, or redundant, or incomplete? I will add them to the test when OK.
> 
> New tests are always welcome, especially for interfaces, as they are a relatively new feature.

@mrserb 
I updated PR, could you review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2664989438