I really enjoy working with Kotlin, but I was curi...

# getting-started

[Bhaskar Singh]

I really enjoy working with Kotlin, but I was curious about one aspect of its design. Why does Kotlin introduce the concepts of properties and fields? Could you please help me understand the reasoning behind this?

In Java, classes have variables and methods, which feel quite straightforward. However, in Kotlin, we have properties, which are essentially variables with accessors, and sometimes these properties might involve fields or even backing properties. While as far as I can understand field and backing property are same

[Sam]

Actually, the concept of a field comes from Java too. In Java, a field is a variable that’s a member of a class. What you described as a Java variable in your message would normally be described as a field, to distinguish it from local variables declared inside functions.

Non-private fields in Java are almost always paired with accessors, largely to get around the fact that fields themselves aren’t polymorphic. Like many other languages, Kotlin chose to combine the field and the accessors into a single construct, which is called a property. If you were to look at the Kotlin compiler’s output, you’d see that adding a var property to a class results in the same bytecode as a Java field with a getter and a setter. Kotlin’s syntax is more concise, but the underlying machinery is the same, as are the problems it’s solving.

So, a typical Kotlin property still contains a field as part of its implementation. This is called the property’s backing field. You normally don’t need to worry about it, since it’s created automatically and invisibly. You’ll only ever see it if you choose to customize the property’s existing implicitly generated accessors. By providing your own implementation for the property’s accessors, you can also declare a property that doesn’t use a backing field at all—in the same way that you could declare accessor-like methods without a corresponding field in Java.

As for the term backing property, that’s not something created for you implicitly by Kotlin. Instead, it describes a particular way of using properties in your own classes. Specifically, if you create two properties, and customize the first property’s accessors so they pull data from the second property, you could describe the second property as a backing property for the first. This isn’t something you’d need to do very often. I’ve seen backing properties used when the public property and its private backing property need to have different types—for example when a list should be mutable within the class but read-only from outside. A future change to the language will likely make it possible to do that all as part of a single property, instead of needing two.

[CLOVIS]

In Java, having a field by itself is actually discouraged; Java programs should have a getter and a setter instead of public fields. In Kotlin, we don't really introduce a new concept, we introduce a new syntax to declare all three (private variable, public getter, public setter) in a single declaration, because it's quite verbose to do all three.

The following Java code:

final class Point {
    private final int x;
    private final int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() { return x; }
    public int getY() { return y; }
}

is exactly equivalent to the following Kotlin code:

class Point(
    val x: Int,
    val y: Int,
)

Properties aren't really a "new thing", they're just a concise way to use fields in the correct™ way more easily.

I wrote a blog post about this and other Kotlin design decisions that were inspired by Java:
https://ivan.canet.dev/blog/2024/12/16/better-java-3.html#item-16-use-public-accessors-not-public-fields