Open in app

Sign up

Sign in

Write

Sign up

Sign in

ProAndroidDev

The latest posts from Android Professionals and Google Developer Experts.

Follow publication

Kotlin to Solve Type Erasure, and a Practical Guide on , , and More

Ioannis Anifantakis
ProAndroidDev
Published in
13 min readFeb 23, 2025

Introduction

Kotlin has become very popular, especially for writing native Android apps and recently for multiplatform apps. One of its most powerful features which is a little hard to understand are functions used together with type parameters. These functions let you write type-safe code and avoid problems caused by type erasure, without relying on slow reflection.

In this guide, I will explain how these functions work, why they are so useful, show a real-world example using type-safe navigation in Android, and discuss their performance benefits. We will build up the concepts step by step, so you can fully understand the reasoning behind this approach.

The Problem: Generics and the Vanishing Type

Before we introduce the solution, we need to clarify the problem. It all starts with generics.

Generics are a wonderful way to write reusable code that can handle different data types. For example, you might want a list that holds various elements — numbers, strings, or custom objects. Generics allow you to do this without writing separate code for each type.

val stringList: List<String> = listOf("apple", "banana", "orange")
val numberList: List<Int> = listOf(1, 2, 3)

In this example, we have two lists: one for values and one for values. and are the generic type parameters, which tell the compiler what type of data each list can contain.

This feature is called compile-time type safety: the compiler detects mistakes early. If you try to add a number to , the compiler will raise an error.

However, there is a catch: the detailed type information (, , or another type) is not preserved when your code executes. This phenomenon is called type erasure.

Understanding Type Erasure

When Kotlin compiles your code, it removes the detailed generic type information. For example, both and end up as list of unknown type at runtime.

Often, people say “they become ” for simplicity, but it’s more accurate to consider them as raw or wildcard types ().

While generics help you catch mistakes during compilation, they do not carry detailed type information at runtime, since that information is erased.

Type Erasure: Why does Erasure exist?

This concept of type erasure exists because of how the Java Virtual Machine (JVM), which Kotlin runs on, handles generics. It was introduced for backward compatibility with older Java code that did not use generics.

To allow newer, generic code to work with older libraries, the JVM “forgets” the specific type parameters at runtime. As a result, both and effectively become , and the JVM no longer distinguishes between them.

The Consequences of Type Erasure

This “forgetting” has some important consequences:

  • No Runtime Type Checks: You cannot check at runtime whether a list is a or a because that “type information” no longer exists.
  • Casting Limitations: You cannot simply cast an object to a generic type parameter (for example, “cast this object to type ”) because the runtime does not know what is.

Example of Type Erasure Limitation

fun <T> printClassName(obj: T) {
    println(obj::class.java.name)
}

fun main() {
    val listOfStrings: List<String> = listOf("Kotlin", "Java")
    printClassName(listOfStrings) // The runtime only sees it as a List, not List<String>
}

We expect to output "List<String>". But it outputs the raw type ( or similar) because the generic type information () is lost. The function sees a generic , not the specific .

The Solution: to the Rescue

This is where comes into play. By using these two keywords together, you can maintain type information at runtime, thus overcoming the limitations caused by type erasure.

  • : This keyword tells the compiler to copy (or “inline”) the entire function’s code into the location where it is called. Instead of calling a separate function, the function’s body is embedded directly. This can also improve performance in some scenarios (more on that later).
  • : This keyword, which can only be used with functions, ensures the type parameter becomes “real” (reified) at runtime. It instructs the compiler to keep type information for that parameter.

Let’s modify our previous example:

inline fun <reified T> printClassName(item: T) {
    println(T::class.java.name) // Now this works!
}

fun main() {
    val myList = listOf("hello", "world")
    printClassName(myList) // Output: java.util.ArrayList (or similar, but the important part is...)
    printClassName("hello")   // Output: java.lang.String
    printClassName(123)      // Output: java.lang.Integer
}

Let’s Explore further

To deeply understand the mechanics and the reasons between and , I have prepared a real example that highlights the concept.

Real Scenario: Type-Safe Navigation in Android

In Android Navigation 2.8 and onward, there is built-in support for TypeSafety.

You define in a data class the parameters to pass from one screen to another. You can also pass data classes via serialization. However, to pass custom data types, you need to specify a certain , which helps the system serialize and deserialize the custom type when navigating between screens.

 val PersonType = object : NavType<Person>(
      isNullableAllowed = false
  ) {
    override fun put(bundle: Bundle, key: String, value: Person) {
        bundle.putParcelable(key, value)
    }

    override fun get(bundle: Bundle, key: String): Person? {
        return if (Build.VERSION.SDK_INT < 34) {
            @Suppress("DEPRECATION")
            bundle.getParcelable(key)
        } else {
            bundle.getParcelable(key, Person::class.java)
        }
    }

    override fun parseValue(value: String): Person {
        return Json.decodeFromString<Person>(value)
    }

    override fun serializeAsValue(value: Person): String {
        return Json.encodeToString(value)
    }

    override val name = Person::class.java.name
}

With this code, you define a custom for the data class . Now you can pass a full object as a parameter with the new navigation component.

But notice how lengthy the code is. It works for one type, but if you have multiple types—like and —duplicating this logic can lead to boilerplate and mistakes.

We obviously need to replace our with a type here to get the job done so we don’t repeat all this code if we want to pass for example a as well.

Attempt 1: A Generic Function (But It Fails)

We might wrap the snippet inside a function, replacing for a generic type . That should give us the freedom to reuse the same logic for any type, instead of rewriting everything for every type.

fun <T : Parcelable> NavType.Companion.mapper(): NavType<T> {
    return object : NavType<T>(
        isNullableAllowed = false
    ) {
        override fun put(bundle: Bundle, key: String, value: T) {
            bundle.putParcelable(key, value)
        }

        override fun get(bundle: Bundle, key: String): T? {
            return if (Build.VERSION.SDK_INT < Build.VERSION_CODES.TIRAMISU) {
                @Suppress("DEPRECATION")
                bundle.getParcelable(key)
            } else {
                bundle.getParcelable(key, T::class.java)
            }
        }

        override fun parseValue(value: String): T {
            return Json.decodeFromString<T>(value)
        }

        override fun serializeAsValue(value: T): String {
            return Json.encodeToString(value)
        }

        override val name = T::class.java.name
    }

This seems perfect, but it does not compile. The problem is still type erasure. We cannot call because the runtime does not know what is.

Attempt 2: Introducing

This is where comes in. By adding the keyword before , we tell the compiler to preserve the type at runtime.

val personType = NavType.mapper<Person>()
val carType = NavType.mapper<Car>() 

fun <reified T : Parcelable> NavType.Companion.mapper(): NavType<T> { 
  // same code here
}

Now, is valid. We can access ’s class at runtime because makes a real type in the function. But we still get a compiler error:

Attempt 3: The Missing Piece —

We are almost there. The compiler insists that can only be used within functions. Why?

Here’s the key: To make work, the compiler needs to know the actual type of at the place where the function is called. It can't just pass a generic around. It needs to substitute with , , or whatever type we're using.

The inline keyword enables this by letting the compiler embed the function body directly at the call site, instead of using a traditional function call.

Think of it this way: when we call , the compiler knows T is . Because the function is inline, it creates a specialized version of the function, replacing T with throughout its body:

val personType = NavType.mapper<Person>()
val carType = NavType.mapper<Car>()

inline fun <reified T : Parcelable> NavType.Companion.mapper(): NavType<T> { 
  // same code here
}

This is why and must be used together. requires the actual type information at the call site, and provides the mechanism to perform that substitution.

inline reified TL;DR

Let’s summarize why goes hand-by-hand with

To maintain the type at runtime, any marked as gets replaced by its concrete type at compile time, producing behind the scenes a new function in which every occurrence of is replaced by concrete type.

The compiler then inlines this specialized version of the function at the caller site, since inline allows the function body to be copied and adapted with the concrete types. Without inline, the compiler could not generate or embed this specialized function.

inline keyword — Performance Improvements

provides type safety, but the keyword also offers potential performance improvements.

places the function’s code directly where it is called, avoiding the usual overhead of a function call (like stack operations and function lookups).

This is especially helpful when working with lambdas. When you pass a lambda to a regular function, an object is created. Inline functions avoid creating that object, which makes them much more efficient. Kotlin’s collection functions (, , ) are inline for this exact reason: they rely heavily on lambdas.

However, inlining also has downsides. It can grow the size of your code, especially if the function is large or used in many different places (often called code bloat).

In summary, other than addressing issues, inlining by itself is a performance strategy, usually best for small, frequently called functions — especially those that accept lambdas. It might not be suitable for large functions or those called from many locations, since it can lead to code bloat/increased bytecode size and make your app bigger.

Controlling Inlining: `noinline` and `crossinline`

While offers significant advantages, Kotlin provides further control over the inlining process with two important modifiers: and . These modifiers are used with lambda parameters of functions.

— Preventing Lambda Inlining

Sometimes, you might want to use an function for its performance benefits (or for types) but not inline a specific lambda parameter. This is where comes in. You mark the lambda parameter with to prevent it from being inlined.

There are two primary reasons to use :

1. Passing the Lambda to Another Non-Inline Function: If you need to pass the lambda to another function that is not marked , you must use . If you try to pass an inlined lambda to a non-inline function, you’ll get a compiler error. The lambda needs to exist as a separate object to be passed.

// NON inline function
fun anotherFunction(lambda: () -> Unit) {
  lambda()
}

// inline function
inline fun doSomething(first: () -> Unit, noinline second: () -> Unit) {
  first()                 // This lambda will be inlined
  anotherFunction(second) // 'second' is passed as a regular lambda object (not inlined)
}

In this example, will be inlined as usual. , however, is marked . This prevents its code from being copied into and allows it to be passed as a function object to .

2. Controlling Code Size: If you have an function with a very large lambda, inlining that lambda repeatedly could lead to significant code bloat. Using prevents this.

inline fun processData(data: List<String>, noinline largeProcessingLogic: (String) -> Unit) {
    for (item in data) {
        // Some small, frequently executed code that benefits from inlining
        if (item.isNotEmpty()) {
            largeProcessingLogic(item)
        }
    }
}

fun main() {
    val data = listOf("a", "b", "", "c", "d", "", "e")

    processData(data) { item ->
      // Imagine this is a VERY large lambda, with hundreds of lines
      // of complex logic, database calls, network requests, etc.
    }
}

Without , the entire lambda would be copied into the loop for each call to processData, drastically increasing the bytecode size. With , only a reference to the lambda is passed, avoiding code duplication.

crossinline — Managing Non-Local Returns

helps you control how the keyword works inside lambdas passed to functions. It makes behave in a more predictable way.

  • Normal (in regular functions and non-inline lambdas): A statement exits only the lambda or function it’s directly inside.
  • Non-Local (in functions, without ): A statement inside an inlined lambda exits the function that called the function. This can be surprising!
  • Local (with ): prevents non-local returns. A inside a lambda will only exit the lambda itself, just like a normal .
// Example 1: Non-Local Return (without crossinline)
inline fun doSomething(action: () -> Unit) {
    println("Start doSomething")
    action()
    println("End doSomething") // This might NOT be printed
}

fun test1() {
    doSomething {
        println("Inside lambda")
        return // This exits test1(), NOT just the lambda!
    }
    println("This will NOT be printed")
}

// Example 2: Local Return (with crossinline)
inline fun doSomethingSafely(crossinline action: () -> Unit) {
    println("Start doSomethingSafely")
    action()
    println("End doSomethingSafely") // This WILL be printed
}

fun test2() {
    doSomethingSafely {
        println("Inside lambda")
        return@doSomethingSafely // This exits ONLY the lambda
    }
    println("This WILL be printed")
}

fun main() {
    println("Running test1:")
    test1() // Output: Start doSomething, Inside lambda

    println("\nRunning test2:")
    test2() // Output: Start doSomethingSafely, Inside lambda, End doSomethingSafely, This WILL be printed
}
  • : The inside the lambda exits completely. "End doSomething" and "This will NOT be printed" are never reached.
  • : The keyword forces the to be local. It only exits the lambda, not . "End doSomethingSafely" and "This WILL be printed" are executed.

Compiler Error: If you try to pass a lambda marked with to another lambda or anonymous object, you will get a compiler error.

Use when:

  • You want the in a lambda to behave like a normal (exiting only the lambda).
  • You are making a library, and you want to make sure users of your function don't accidentally use non-local returns, which could change the flow of their program in unexpected ways.

Summary of Modifiers

  • : Copies the function's code and lambda code (by default) to the place where it's called. Allows in a lambda to exit the calling function (non-local return).
  • : Prevents a specific lambda parameter from being inlined. Necessary for passing lambdas to non-inline functions.
  • : Allows a lambda to be copied (inlined), but forces to only exit the lambda itself (local return).

Limitations and When Reflection is Necessary

is a powerful tool, but it’s not a universal solution. There are specific situations where it cannot be used. In these cases, reflection (or other, less common workarounds) becomes necessary.

Here are some key scenarios where cannot be used:

  1. Dynamic Type Discovery: If you truly don’t know the type of an object until runtime, you can’t use . requires the type to be known where you call the function. For example, if you’re reading data from a file and the file format dictates the data type, you won’t know the type until you’ve read the file. Reflection would be needed here.
  2. Interacting with Non-Kotlin Code (Without Known Types): If you’re calling Java code (or code from other JVM languages) that doesn’t provide generic type information in a way that Kotlin can understand, you might not be able to use `reified`. You might need to use reflection to interact with the returned objects.
  3. Interface method with default implementation: If the method with is declared inside an Interface with default implementation.
  4. Recursive functions: You can’t use with functions that call themselves ("recursive" functions). The computer copies the function's code each time it's used. If a function calls itself, this copying would never stop.
  5. Accessing Non-Public Members (Without ): functions can’t directly access non-public members of a class unless those members are marked with the annotation.
  6. Variable Type Arguments: You cannot use a variable as a type argument for a reified type.
inline fun <reified T> myFun() {
  println(T::class.simpleName)
}

fun <T> otherFun() {
   myFun<T>() // Compilation error
}

In the code above, we are trying to use the type variable as a type argument. But this is not allowed.

Reflection: The Alternative (and Its Costs)

When isn’t an option, reflection is often the fallback. Reflection allows a program to inspect and manipulate the structure and behavior of objects at runtime. This includes examining types, accessing fields, and invoking methods, even if those elements are not known at compile time.

However, this power comes at a cost:

  • Speed: Reflection is significantly slower than direct type access. It involves dynamic lookups and checks that add overhead.
  • Type Safety: Reflection doesn’t check types when you write your code. This means you might get errors when your program runs that you would normally find earlier.
  • Code Complication: Code that uses reflection is often longer and harder to understand.

Reflection can do some of the same things as , but it's usually slower, less safe, and harder to use. is the best way to do this in most cases where you need to know the type while the program is running.

Another Alternative: KClass

Another approach, particularly when you just need to know the of a type, is to pass a object as an argument to your function. is Kotlin’s representation of a class.

It’s like a blueprint of the class, providing information about its properties, functions, and constructors. For example:

fun <T : Any> printClassName(obj: T, clazz: KClass<T>) {
   println("The class name is: ${clazz.simpleName}")
}

fun main() {
  printClassName("Hello", String::class) // Pass String::class
  printClassName(123, Int::class)        // Pass Int::class
}

This works, but it adds extra code, you have to explicitly pass the every time you call the function. avoids this extra step because the compiler automatically inserts the type information.

It’s important to understand that is not a complete replacement for . provides information about a type, while allows you to use a type as if it were concrete, even in the presence of type erasure.

They serve different, though related, purposes. gives you more power within the function where it's used.

Conclusion

is a powerful feature in Kotlin that solves the problem of type erasure while providing performance advantages.

By using and together, you can write code that is generic, type-safe, and efficient. It avoids repetitive code (as in our Android Navigation example) and removes the reflection overhead otherwise needed to access runtime type information.

Learning how to use inline reified effectively helps you create cleaner, more maintainable, and faster Kotlin code, whether you are developing Android apps, managing complex data, or working with Java libraries.

It is an essential tool for improving the quality and performance of your Kotlin projects.

Further Reading

Kotlin Official Documentation

  • Inline functions: The official Kotlin documentation explaining inline functions, performance benefits, and how they work with lambdas and /.
  • Reified type parameters: Specifically focuses on reified type parameters within inline functions, detailing how they address type erasure.
  • Generics: A comprehensive overview of generics in Kotlin, essential for understanding the context of type erasure and .

Blog

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Sign up for free

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Try for $5/month
Kotlin
Android App Development
AndroidDev
Programming
Software Engineering

ProAndroidDev
ProAndroidDev
Follow

Published in ProAndroidDev

71K Followers
Last published 3 days ago

The latest posts from Android Professionals and Google Developer Experts.

Follow
Ioannis Anifantakis
Ioannis Anifantakis
Follow

Written by Ioannis Anifantakis

2.7K Followers
60 Following

Android Engineer | Senior Consultant @ Deloitte https://anifantakis.eu https://www.linkedin.com/in/anifantakis/ https://www.youtube.com/@IoannisAnifantakis

Follow

Responses (5)

Write a response

What are your thoughts?

More from Ioannis Anifantakis and ProAndroidDev

See all from Ioannis Anifantakis
See all from ProAndroidDev

Recommended from Medium

See more recommendations