Implementing a Kotlin property from a Java interface

Question

Consider the following Java interface

interface Foo {
    String getValue();
}

In Kotlin, get/set functions are converted to properties, so I would expect the implementation to look like this

class FooImpl : Foo {
    val value: String get() = "Hello, World!"
}

But I actually have to implement the method as it is in the interface

class FooImpl {
    override fun getValue(): String {
        return "Hello, World!";
    }
}

Why?

BambooleanLogic · Accepted Answer · 2023-02-10 20:55:30Z

7

Kotlin makes an explicit difference between methods and properties. They are not considered the same thing; it just so happens that both are compiled down to methods in the end since the JVM doesn't natively support properties. As such, a method cannot implement a property since they're fundamentally different.

The reason why you can't implement a Java getter with a property is the same reason as why you can't implement a Kotlin-defined fun getX(): String with an override val x: String; they're just not compatible.

The confusion here seems to stem from how Kotlin allows you to access Java getters with a property-like syntax, i.e. val foo = obj.x is equivalent to val foo = obj.getX() if the class is defined in Java.

This is strictly a one-way relationship to make Kotlin code that interoperates with Java code slightly more compact and "Kotlin-like"; this syntactical shortcut doesn't extend to implementing the method as if it were a property.

Additionally, if you were to implement a method as a property, that would probably lead to strange effects. Arguably, it would be both a method and a property at the same time, which would not only be weird, but would likely lead to a lot of other unexpected behaviors and edge cases in the language. (For instance, how would it be treated when using reflection?)

edited Feb 10, 2023 at 20:55

answered Feb 10, 2023 at 20:45

BambooleanLogic

8,2273 gold badges36 silver badges57 bronze badges

Sign up to request clarification or add additional context in comments.

3 Comments

Matthew Layton Over a year ago

I thought that properties in Kotlin were simply syntactic sugar over get/set functions, like they are in C#. If you tried to create a C# class with a property called string Foo { get; } and then tried to defined a method called string get_Foo(), the compiler will complain that you've already defined the method. So, what is it exactly that makes Kotlin properties different from get/set methods?

BambooleanLogic Over a year ago

A programming language isn't a single model. There's the "language model" that describes what features and concepts can be described in the code. The model after compilation (the JVM) may be completely different. Stuff in the language model (say, generics) may differ or be absent, or vice versa. The language treats methods, properties, and also constructors as different things. Yes, all can contain code, but their abilities, rules. and uses differ. When compiled, they're all mapped to simple JVM methods because the distinction is only useful in the language; the JVM itself doesn't care.

BambooleanLogic Over a year ago

So why do we need them? Well, we don't; Java has managed without them for 25+ years. But they do have many benefits. First, declaring fields and accessors in one go is more compact. Second, unifying fields and accessors as a single concept solves the underlying encapsulation and compatibility issues in a simple way. Third, being able to refer to a way to get/set a piece of data as a singular thing, a property, instead of two method references helps with advanced features such as serialization or injection. Fourth, property delegates are awesome. I could go on, but I'm out of characters.

Collectives™ on Stack Overflow

Implementing a Kotlin property from a Java interface

1 Answer 1

3 Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

3 Comments

Your Answer

Sign up or log in

Post as a guest

Related