# Why Kotlin's inline and reified Keywords Exist (And How They Solve Java's Oldest Flaw)

DevFeed: [Why Kotlin's inline and reified Keywords Exist (And How They Solve Java's Oldest Flaw)](<https://devfeed.tech/articles/why-kotlin-s-inline-and-reified-keywords-exist-and-how-they-solve-java-s-oldest-flaw-60627.md>)

Original publisher: [Read original article](<https://proandroiddev.com/why-kotlins-inline-and-reified-keywords-exist-and-how-they-solve-java-s-oldest-flaw-f390508339cd?source=rss----c72404660798---4>)

Author: Sehaj kahlon

Published: 2026-09-27T16:58:44Z

Content type: tutorial

Language: en

Sources: [ProAndroidDev](<https://devfeed.tech/sources/proandroiddev-medium.md>)

Topics: [Reified Type Parameter](<https://devfeed.tech/topics/reified-type-parameter.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [java](<https://devfeed.tech/tags/java.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [mobile-app-development](<https://devfeed.tech/tags/mobile-app-development.md>), [software-development](<https://devfeed.tech/tags/software-development.md>), [type-parameter](<https://devfeed.tech/tags/type-parameter.md>)

## AI overview

The article explains how Kotlin's inline and reified keywords work together to make generic type information available at runtime on the JVM, despite type erasure. It describes inline function expansion and contrasts Kotlin's approach with passing Java Class tokens.

## Source excerpt

Why some of the most elegant APIs in Kotlin -- first<T>(), Gson().fromJson<T>(), Jetpack's viewModels<T>() -- could never have existed without two keywords most developers use daily but rarely stop to understand. inline fun makeInstance(): T = T::class.java.getDeclaredConstructor().newInstance() Generics on the JVM have a strict rule: you cannot use a type parameter T at runtime. Calling T::class, instantiating new T(), or checking if (x is T) is normally forbidden. The compiler will complain that the type information is missing. Yet, this function compiles and works flawlessly. The secret lies in two keywords: inline and reified. Understanding how they interact changes how you read idiomatic Kotlin, from JSON parsers to network clients. The Problem: The JVM's Amnesia When you write generic code, you use T as a placeholder for a future type: class Box(val value: T) val intBox = Box(5) // T is Int val stringBox = Box("hello") // T is String At compile time, Kotlin knows exactly what T is. It uses this knowledge to catch mistakes, immediately stopping you if you try to put a String into intBox. But when compiled to run on the JVM, this knowledge vanishes. This design decision is called type erasure. Introduced for backward compatibility in 2004, Java's generics are largely a compile-time illusion. At runtime, the JVM simply sees "a Box holding an Object." The concrete type is erased. Because of this, you cannot use a generic type parameter as a real class at runtime. In standard Java, the workaround is tedious: you must manually pass a Class token everywhere just to keep the type around. Kotlin found a way to bypass this entirely. The First Half of the Trick: inline To understand the solution, we first need to look at inline--a keyword that originally has nothing to do with generics. Normally, a function call is a detour. The program jumps to the function's location in memory, executes it, and jumps back. Every caller shares one compiled copy of the function. Marking a f