<Beans Dev> [11] Review Request: 8196373 Introspector does not see overridden generic setter method

[Sergey Bylokhov]

Hello.
The fix updated after discussion:
http://cr.openjdk.java.net/~serb/8196373/webrev.01

The type of the property will be set to the type of setXX() only when 
getXX() is missing, otherwise the type of getXX() will be used.

On 30/04/2018 09:02, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk11.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196373
> Webrev: http://cr.openjdk.java.net/~serb/8196373/webrev.00
> 
> One more places which depends from the order of methods is fixed.
> The bug is occurred in the next code example:
> ===============================
>      static class Parent<T> {
>          public final T getValue()
>          protected void setValue(T value)
>      }
>      static class ChildS extends Parent<String> {
>          @Override
>          public void setValue(String value)
>      }
> ===============================
> 
> The problem is that javac will generate the "synthetic bridge" method
> setValue(Ljava/lang/Object) in the ChildS class to support such 
> generics. This method may be placed before/after the real 
> setValue(String value) method.
> 
> PropertyInfo class which generate the property according set/get methods 
> for one particular class depends on the order of these methods, it does 
> not update the type of the property when the preferred "write" method is 
> found. This is why the bug is reproduced when generic type is String(the 
> "String" method is placed after setValue(Object)) and is not reproduced 
> when the type is ArithmeticException(the "ArithmeticException" method is 
> placed before setValue(Object)).
> 
> Three tests were added:
>   - OverriddenGenericSetter.java - to check an example above and prove 
> that the bug is fixed.
>   - OverriddenGenericGetter.java - to check that the similar case for 
> "getter" works properly
>   - OverloadedSetter.java - to check some unspecified but existed 
> behavior, it can be used to check our implementation for accidental changes
> 
> Any suggestions are welcome.
> 


-- 
Best regards, Sergey.