What's Kotlin Backing Field For?

Question

As a Java developer, the concept of a backing field is a bit foreign to me. Given:

class Sample {     var counter = 0 // the initializer value is written directly to the backing field     set(value) {         if (value >= 0) field = value     } } 

What's this backing field good for? Kotlin docs said:

Classes in Kotlin cannot have fields. However, sometimes it is necessary to have a backing field when using custom accessors.

Why? What's the difference with using the properties name itself inside the setter, eg.*

class Sample {             var counter = 0     set(value) {         if (value >= 0) this.counter = value // or just counter = value?     } } 

Answer 1

Because, say if you don't have field keyword, you won't be able to actually set/get the value in the get() or set(value). It enables you to access the backing field in the custom accessors.

This is the equivalent Java code of your sample:

class Sample {     private int counter = 0;     public void setCounter(int value) {         if (value >= 0) setCounter(value);     }     public int getCounter() {         return counter;     } } 

Apparently this is not good, as the setter is just an infinte recursion into itself, never changing anything. Remember in kotlin whenever you write foo.bar = value it will be translated into a setter call instead of a PUTFIELD.

---

EDIT: Java has fields while Kotlin has properties, which is a rather higher level concept than fields.

There are two types of properties: one with a backing field, one without.

A property with a backing field will store the value in the form of a field. That field makes storing value in memory possible. An example of such property is the first and second properties of Pair. That property will change the in-memory representation of Pair.

A property without a backing field will have to store their value in other ways than directly storing it in memory. It must be computed from other properties, or, the object itself. An example of such property is the indices extension property of List, which is not backed by a field, but a computed result based on size property. So it won't change the in-memory representation of List (which it can't do at all because Java is statically typed).