Reified Type Parameters in Kotlin

Reified Type Parameters lösen ein konkretes Kotlin-Problem: Generics sind zur Compile-Zeit sehr stark, verlieren aber normalerweise viele Typinformationen zur Laufzeit. Wenn du Android-Apps mit Kotlin schreibst, triffst du genau an dieser Grenze auf praktische Fragen: Welcher Typ steckt in einem Ergebnis? Welche Klasse soll gestartet, geladen oder geprüft werden? Reified Generics geben dir dafür ein präzises Werkzeug, solange du sie bewusst in inline-Funktionen einsetzt.

Was ist das?

Ein Type Parameter ist der Platzhalter in einer generischen Funktion oder Klasse, zum Beispiel T in List<T> oder fun <T> parse(...). Er erlaubt dir, Code für unterschiedliche Typen zu schreiben, ohne für jeden Typ eine eigene Funktion anzulegen. Das ist in Kotlin normaler Alltag: Listen, Result-Wrapper, Repository-Funktionen, Mapper und UI-State-Modelle arbeiten häufig generisch.

Das Problem entsteht, wenn du zur Laufzeit wissen willst, welcher konkrete Typ hinter T steckt. Auf der JVM werden generische Typinformationen durch Type Erasure größtenteils entfernt. Das bedeutet: Der Compiler kennt T, aber zur Laufzeit kannst du normalerweise nicht direkt fragen: „Ist dieses Objekt ein T?“ oder „Gib mir T::class“. Ein normaler generischer Type Parameter ist dafür nicht konkret genug.

reified bedeutet in Kotlin: Der Typ bleibt in einer inline-Funktion so verfügbar, dass du ihn im Funktionskörper wie einen echten Typ verwenden kannst. Du kannst dann zum Beispiel value is T, T::class oder T::class.java nutzen. Das ist kein allgemeiner Ersatz für Generics, sondern eine spezielle Technik für Funktionen, die der Compiler beim Aufruf direkt in den aufrufenden Code einfügt.

Im Android-Kontext ist das wichtig, weil du oft Brücken zwischen Kotlin-Typen und Laufzeit-APIs baust. Android-APIs erwarten an vielen Stellen Class-Objekte, Schlüssel, Intent-Ziele, Serializer oder konkrete Typprüfungen. Reified Type Parameters helfen dir, solche Stellen lesbarer zu machen und weniger Fehler durch manuell übergebene Klassenparameter zu erzeugen.

Das mentale Modell ist: Normale Generics beschreiben Typen für den Compiler. Reified Generics machen den konkreten Typ in einer inline-Funktion auch im erzeugten Code greifbar. Du bekommst also keine neue Magie für alle Generics, sondern eine kontrollierte Ausnahme an einer klaren Stelle.

Wie funktioniert es?

Reified Type Parameters funktionieren nur zusammen mit inline. Das ist die zentrale Regel. Eine Funktion wie diese ist nicht erlaubt:

fun <reified T> broken(value: Any): Boolean {
    return value is T
}

Der Compiler lehnt das ab, weil reified ohne inline keinen Sinn ergibt. Bei einer normalen Funktion gäbe es zur Laufzeit keinen konkreten Typ für T, auf den der Code zugreifen könnte. Erst durch inline kann der Compiler den Funktionskörper an die Aufrufstelle kopieren und dort den echten Typ einsetzen.

Eine gültige Variante sieht so aus:

inline fun <reified T> Any?.isType(): Boolean {
    return this is T
}

Wenn du item.isType<String>() aufrufst, kann der Compiler an dieser Stelle mit String arbeiten. Der generische Platzhalter ist nicht mehr nur ein abstraktes T, sondern wird im Kontext des Aufrufs konkret.

Das ist besonders nützlich für drei Arten von Aufgaben. Erstens kannst du Typprüfungen schreiben, ohne eine Class<T> oder KClass<T> manuell zu übergeben. Zweitens kannst du APIs kapseln, die eine Java-Klasse brauchen, etwa T::class.java. Drittens kannst du Helper-Funktionen bauen, die lesbarer sind, weil der Typ im Aufruf steht und nicht als zusätzlicher Parameter daneben.

Trotzdem solltest du reified nicht als Standard für jede generische Funktion verwenden. inline verändert, wie Code erzeugt wird. Kleine Helper-Funktionen sind dafür gut geeignet. Große Funktionen mit viel Logik, vielen lokalen Variablen oder komplexen Kontrollflüssen solltest du nicht nur wegen Bequemlichkeit inline machen. Der Code wird an jeder Aufrufstelle eingefügt, was bei übermäßigem Einsatz die erzeugte Bytecode-Größe erhöhen kann.

Außerdem löst reified nicht alle Probleme mit generischen Typen. Bei verschachtelten Generics wie List<User> musst du weiterhin verstehen, welche Information zur Laufzeit wirklich verfügbar ist. Du kannst T::class verwenden, aber der innere Typ einer Liste ist auf der JVM nicht automatisch vollständig erhalten. Für JSON, Navigation oder Persistenz brauchst du deshalb je nach Bibliothek weiterhin passende Serializer, Type Tokens oder explizite Adapter.

Ein weiterer Punkt: Reified Type Parameters sind an Kotlin gebunden. Java-Code kann solche Funktionen nicht auf dieselbe Weise aufrufen, weil Java kein entsprechendes Sprachkonstrukt kennt. In reinen Kotlin-Modulen ist das selten ein Problem. In gemischten Codebasen solltest du aber prüfen, ob eine API auch von Java aus genutzt werden muss.

In der Praxis

In Android-Projekten begegnet dir reified häufig bei kleinen, typbezogenen Hilfsfunktionen. Ein klassisches Beispiel ist das Starten einer Activity. Die Android-API erwartet normalerweise eine konkrete Klasse:

val intent = Intent(context, DetailActivity::class.java)
context.startActivity(intent)

Das ist nicht schlimm, aber du kannst daraus eine klare Kotlin-Erweiterung bauen:

inline fun <reified T : Activity> Context.startActivityOf() {
    val intent = Intent(this, T::class.java)
    startActivity(intent)
}

// Verwendung:
context.startActivityOf<DetailActivity>()

Hier sorgt reified T dafür, dass T::class.java im Funktionskörper verfügbar ist. Die Einschränkung T : Activity ist ebenfalls wichtig. Sie sagt dem Compiler: Dieser Helper ist nur für Activity-Typen gedacht. Dadurch wird falsche Nutzung früh sichtbar.

Ein etwas praxisnäheres Beispiel ist eine Funktion, die ein Objekt aus einem gemischten Result-Container liest. Solche Container können in UI-Schichten, Event-Bussen, Test-Doubles oder Migrationscode vorkommen. Du solltest solche Muster nicht überall einführen, aber wenn sie existieren, kann reified den Zugriff kontrollierter machen:

class DataStore {
    private val values = mutableMapOf<String, Any>()

    fun put(key: String, value: Any) {
        values[key] = value
    }

    inline fun <reified T> getAs(key: String): T? {
        val value = values[key]
        return if (value is T) value else null
    }
}

data class User(val id: String, val name: String)

val store = DataStore()
store.put("currentUser", User("42", "Mina"))

val user: User? = store.getAs<User>("currentUser")

Die Funktion getAs<User>() ist besser lesbar als eine Variante mit getAs("currentUser", User::class), wenn du sie nur aus Kotlin nutzt. Der Typ steht direkt im Aufruf. Der Compiler kann prüfen, welchen Rückgabetyp du erwartest. Gleichzeitig schützt der is T-Check vor einem unsicheren Cast.

Für moderne Android-Entwicklung ist das vor allem in Architektur- und Infrastrukturcode relevant. In Feature-Code, ViewModels oder Compose-Screens solltest du nicht überall generische Typtricks einbauen. Dort ist expliziter, einfacher Code oft besser wartbar. Reified Generics passen eher in kleine, gut getestete Hilfsfunktionen: Mapper, Factory-Funktionen, Test-Assertions, Intent-Builder, Navigation-Adapter oder dünne Wrapper um Bibliotheks-APIs.

Bei Jetpack Compose kann reified zum Beispiel in Test- oder Preview-Helfern auftauchen, wenn du typisierte Daten aus einem State-Container liest. In ViewModels kann es bei Result-Typen oder Error-Mapping helfen. Bei Repositorys kann es die Übergabe von Klassentypen an Serializer oder lokale Caches vereinfachen. Entscheidend ist immer dieselbe Frage: Braucht diese Funktion den konkreten Typ zur Laufzeit? Wenn nein, reicht ein normaler Type Parameter.

Eine gute Entscheidungsregel lautet: Nutze inline fun <reified T> nur, wenn du im Funktionskörper wirklich T::class, T::class.java, is T, as T oder eine API mit konkretem Runtime-Typ brauchst. Wenn du T nur verwendest, um Eingabe und Ausgabe typisiert zu verbinden, ist reified unnötig.

Eine typische Stolperfalle ist der unsichere Cast:

inline fun <reified T> Any.forceCast(): T {
    return this as T
}

Diese Funktion sieht kurz aus, verschiebt aber das Problem nur. Wenn der Typ nicht passt, bekommst du zur Laufzeit eine Exception. In App-Code ist eine sichere Variante oft besser:

inline fun <reified T> Any?.castOrNull(): T? {
    return this as? T
}

Damit machst du das Risiko sichtbar. Der Aufrufer muss mit null umgehen. In einem ViewModel kannst du daraus einen sauberen Fehlerzustand bauen, statt die App an einer unerwarteten Stelle abstürzen zu lassen.

Auch beim Testen ist reified hilfreich. Du kannst zum Beispiel Assertions schreiben, die prüfen, ob ein Ergebnis einen bestimmten Typ hat:

sealed interface UiResult {
    data object Loading : UiResult
    data class Success(val items: List<String>) : UiResult
    data class Error(val message: String) : UiResult
}

inline fun <reified T : UiResult> UiResult.shouldBeType(): T {
    check(this is T) {
        "Expected ${T::class.simpleName}, but was ${this::class.simpleName}"
    }
    return this
}

val result: UiResult = UiResult.Success(listOf("A", "B"))
val success = result.shouldBeType<UiResult.Success>()

Solche Helfer können Tests klarer machen, weil du direkt ausdrückst, welchen Zustand du erwartest. Gleichzeitig bleibt die Funktion klein und konzentriert. Genau dafür eignet sich inline mit reified.

Beim Code-Review solltest du auf drei Fragen achten. Erstens: Wird der Runtime-Typ wirklich gebraucht? Zweitens: Ist die Funktion klein genug, damit inline angemessen bleibt? Drittens: Ist der Cast sicher oder wird ein Fehler bewusst und verständlich behandelt? Wenn eine dieser Fragen nicht sauber beantwortet ist, ist eine explizitere Lösung oft besser.

Fazit

Reified Type Parameters sind ein Kotlin-Werkzeug für den Moment, in dem Generics und Runtime-Type-Information zusammentreffen. Du setzt sie in inline-Funktionen ein, wenn du mit T zur Laufzeit arbeiten musst, etwa für Typprüfungen, Klassenreferenzen oder kleine Android-Helper. Übe das gezielt: Schreibe eine sichere castOrNull-Funktion, debugge den Aufruf mit zwei verschiedenen Typen, und prüfe in einem Test, ob ein falscher Typ sauber behandelt wird. Im Code-Review solltest du jedes reified begründen können: Der konkrete Typ muss im Funktionskörper gebraucht werden, sonst ist ein normaler generischer Parameter die klarere Wahl.