Hi folks! I bumped into the following issue while trying to port a Java library to Kotlin while keep...

# announcements

[Luc Girardin]

Hi folks! I bumped into the following issue while trying to port a Java library to Kotlin while keeping JVM API compatibility (i.e. this is why changing the name of the property or the function is not an adequate workaround for me). Here is a prototypical example of the issue:

import kotlin.jvm.JvmField

open class X(
    @JvmField
    open val x : Int = 0,
) {
    fun getX() : Int = x
}

open class XY(
    @JvmField
    val y : Int = 0
) : X()

Trying to compile this little piece of code for the JVM will produce the following error:

Inherited platform declarations clash: The following declarations have the same JVM signature (getX()I):
    fun <get-x>(): Int defined in XY
    fun getX(): Int defined in XY

It seems that the @JvmField defined in X is not inherited by the XY class. From my perspective, this construct is valid and very useful if one want to keep compatibility with an API that offers both field and method-based access... even though this is usually bad yet common practice.
Thanks for listening!
Luc

[Luc Girardin]

I already filled a bug report at https://youtrack.jetbrains.com/issue/KT-42081 but if someone has a workaround in the meantime that would be extremely helpful!

[Tobias Berger]

For me the first question is: why does this class have a public field and a getter method for that field?

[Tobias Berger]

like you said, it's a bad practice, so ideally it would be removed.

When i run this as a scratch in IntelliJ I have no problems. I'm not sure whether that used the standard compiler though.

[Tobias Berger]

another note: what's the point of having val x marked as open and JvmField? Fields can't be overridden in JVM. having a field with the same name in a child class can lead to confusing behaviour

[Luc Girardin]

Hello Tobias! Even though this is bad practice, it need to mimic the following Java code in Kotlin:

public class X {
    public int x = 0;

    public int getX() {
        return x;
    }
}

public class XY extends X {
    public int y = 0;
}

Then only reason is not to break backward compatibility.

[Luc Girardin]

You are right, open doesn't bring anything to 'val x'. However, getting rid of it leads to the same problem: code doesn't compile using Kotlin 1.4.10.

[nkiesel]

for starters, x and y should be var, no? Because in the Java code they are mutable.

[Luc Girardin]

That's right Norbert... but still with far I get the same compilation error.