Erklären Sie die Funktionsweise der Operatoren '==' und '===' in Kotlin. Was ist die Besonderheit beim Vergleich von Objekten und primitiven Typen, was passiert im Hintergrund während des Vergleichs, und wie kann man den verbreiteten Fehler mit der Äquivalenz vermeiden?

Antwort.

In Kotlin gibt es zwei Operatoren für den Vergleich:

• == — strukturierter Vergleich (entspricht .equals()). Er überprüft den Inhalt: a == b ruft a?.equals(b) ?: (b == null) auf.
• === — Referenzvergleich. Überprüft, ob beide Variablen auf dasselbe Objekt verweisen: a === b entspricht a == b in Java für Objekte.

Für primitive Typen (z.B. Int): == und === können sich aufgrund von Autoboxing gleich verhalten, aber im Allgemeinen sollte == verwendet werden.

Beispielcode

val a = "Kotlin"
val b = "Kotlin"
val c = a

println(a == b)    // true (Inhaltsvergleich)
println(a === b)   // false (verschiedene Referenzen — Strings sind je nach Compiler interniert)
println(a === c)   // true (dasselbe Objekt)

---

Fangfrage.

Was ist der Unterschied zwischen a.equals(b) und a == b in Kotlin?

Einige behaupten, dass es keinen Unterschied gibt, aber wenn a nullable ist, wird der Aufruf a.equals(b) eine NullPointerException auslösen, während a == b sicher ist und true zurückgibt, wenn beide null sind, oder false, wenn nur einer von ihnen null ist.

Beispiel:

val a: String? = null
val b: String? = null
println(a == b)       // true
println(a?.equals(b)) // null (und nicht true, aber kein Absturz)
println(a.equals(b))  // NullPointerException

---

Beispiele für reale Fehler aufgrund mangelnden Wissens über die Feinheiten des Themas.

---

Geschichte

In einem großen Projekt wurden nullable Strings aktiv über a.equals(b) verglichen, ohne zu bemerken, dass bei a == null die Anwendung abstürzt. Der Bug trat ziemlich selten auf, führte aber zu fatalen Abstürzen in der Produktion – behoben wurde er durch den Wechsel zu a == b.

---

Geschichte

Beim Vergleich von Objekten über === wurde ein Inhaltsvergleich erwartet, aber === überprüft die Identität von Objekten – es stellte sich heraus, dass zwei verschiedene Strings mit demselben Inhalt über === nicht gleich sind, was die Logik der Datencache beschädigte.

---

Geschichte

Bei der Arbeit mit boxed Int-Werten (z.B. aus Sammlungen) verglichen Entwickler diese über === und erhielten unerwartete Ergebnisse, da Instanzen verschiedener Zahlen nicht unbedingt wie Primitive interniert werden. Dies führte zu inkorrektem Verhalten bei der Arbeit mit Objekt-Sammlungen.