30aad31ece
The problem from KT-63624 was that during matching phase we must choose only one candidate, but in Java we can have two successfully matched properties: 1) from field and 2) from method, which overrides Kotlin property. See test `propertyAgainstJavaPrivateFieldAndPublicMethod.kt`. As a result, we choose field candidate, throw away method candidate, and then fail during visibility check. Instead of inventing special rule of prioritizing field over method it was decided to prohibit actualization to Java field at all because: 1. It doesn't seem that Java fields actualization was implemented in K1 on purpose 2. People usually don't use public Java fields, and use instead private field + getter, especially when compatibility is important, so it shouldn't be a breaking change Besides that, such solution simplifies code and is consistent with the current logic of matcher, which doesn't expect that two members can be matched successfully. Also, it fixes KT-63624 and KT-63667. ^KT-63624 Fixed ^KT-63667 Fixed