Antwoord.

In Kotlin wordt de modifier const val alleen gebruikt voor compile-time constanten op top-level (op bestandsniveau), of binnen objecten (object) en companion-objecten. Eigenschappen die als val binnen klassen zijn gedeclareerd, worden gewone final properties zonder statische initialisatie. Een belangrijk kenmerk: const val kan niet worden geërfd, maar val kan worden overschreven (als dat is toegestaan).

Constanten (const val) kunnen niet abstract zijn, omdat ze een waarde moeten hebben op compile-tijd. Gewone val stelt je in staat om het constantenpatroon in hiërarchieën te implementeren via open eigenschappen, maar ze zijn tijdens runtime toegankelijk via een getter, wat verschilt van compilatie in Java.

Voorbeeld:

open class Base {
    open val info: String = "base"
}
class Child : Base() {
    override val info = "child"
}

object Constants {
    const val APPLICATION_NAME = "MyApp"
}

Vraag met een valstrik.

Kan const val worden gedeclareerd in een interface of abstracte klasse en vervolgens worden overschreven/geërfd?

Antwoord met voorbeeld:

Nee. In Kotlin kan const val niet binnen een interface of abstracte klasse worden gedeclareerd — dit is alleen toegestaan op niveau van object (object) en top-level. Er zijn geen vergelijkbare static final-velden beschikbaar voor overerving.

interface Foo {
    // const val X = "constant" // compileerfout: const 'val' zijn alleen toegestaan op top-level, in objecten, of in companion-objecten
}

Voorbeelden van echte fouten door gebrek aan kennis over de nuances van het onderwerp.

---

Verhaal

Het team probeerde stringconstantjes te hergebruiken via interface-overerving in verschillende Android-modules, en verklaarde ze als const val — ze kregen een compilatiefout en waren gedwongen de constanten naar top-level te verplaatsen, wat de encapsulatie verslechterde.

---

Verhaal

In het project werden alle Java static final velden omgezet in Kotlin val-velden in open klasses, in de verwachting hetzelfde gedrag (compile-time const) te krijgen, maar ze werden gewone properties met een getter. Dit resulteerde in een langere toegangstijd, wat een negatieve impact had op de hot paths van de microservices-applicatie.

---

Verhaal

Bij het porteren van Java-klassen van constant-container naar Kotlin, maakten ontwikkelaars constanten binnen het companion-object, maar stuitten op een toegangsprobleem vanuit Java-code: de constanten waren zichtbaar als velden van de companion zelf, en niet van de klasse, wat verwarring in de API veroorzaakte en extra interoperabiliteitsbugs.