Hi Sergey, I approve the latest changes.
Thank you, SAM On Sun, May 27, 2018 at 4:13 AM, Sergey Bylokhov <[email protected]> wrote: > 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. -- Best regards, Sergey A. Malenkov
