RuntimeTypeMapper assumed that JavaPropertyDescriptor was necessarily backed by
JavaField, which has changed when we started to load Java method (or a pair of
methods) overriding a Kotlin property as a property, not as a method. Another
example of this situation is special built-in properties which are mapped to
Java methods, e.g. java.util.Collection#size() <-> kotlin.Collection#size. This
change adds support for the case of a property backed by a JavaMethod.
Note that callable references or usage of any reflection API related to
built-in members is not supported anyway and will currently fail with errors
#KT-11258 Fixed
Mostly this commit is about skipping wildcards that are redundant in some sense.
The motivation is that they looks `long` in Java code.
There are basically two important parts: return types and value parameters.
1. For return types default behaviour is skipping all declaration-site wildcards.
The intuition behind this rule is simple: return types are basically used in subtype position
(as an argument for another call), and here everything works well in case of 'out'-variance.
For example we have 'Out<Out<T>>>' as subtype both for 'Out<Out<T>>>' and 'Out<? extends Out<? extends T>>>',
so values of such type is more flexible in contrast to `Out<? extends Out<? extends T>>>` that could be used only
for the second case.
But we have choosen to treat `in`-variance in a different way: argument itself
should be rendered without wildcard while nested arguments are rendered by the rules
described further (see second part).
For example: 'In<Out<OpenClass>>' will have generic signature 'In<Out<? extends OpenClass>>'.
If we omit all wildcards here, then value of type 'In<Out<OpenClass>>'
will be impossible to use as argument for function expecting 'In<? super Out<? extends Derived>>'
where Derived <: OpenClass (you can check it manually :]).
And this exception should not be very inconvinient because in-variance is rather rare.
2. For value parameters we decided to skip wildcards if it doesn't make obtained signature weaker
in a sense of set of acceptable arguments.
More precisely:
a. We write wildcard for 'Out<T>' iff T ``can have subtypes ignoring nullability''
b. We write wildcard for 'In<T>' iff T is not equal to it's class upper bound (ignoring nullability again)
Definition of ``can have subtypes ignoring nullability'' is straightforward and you can see it in commit.
#KT-9801 Fixed
#KT-9890 Fixed
Previously to use reflection on them, you had to wrap an already created object
with a "Reflection.function" or "Reflection.propertyN" call, which the JVM
back-end was doing. This was not optimal in several senses and current solution
fixes that
This proved to be a fragile technique, which probably doesn't even improve
performance in most cases but has lots of unexpected problems: unconditional
initialization of reflection classes, increasing the size of the bytecode, bugs
with <clinit> in annotations on JVM 6, inability to support conversion of a
class from Kotlin to Java without recompiling clients which use it
reflectively, etc.
This syntax is reserved to be likely used in the future as a shorthand for
"this::foo" where the resulting expression doesn't take the receiver as a
parameter but has "this" already bound to it
Alexander Udalov