How Kotlin's inline and reified bypass Java's type erasure
The two keywords that enable runtime generic type access in Kotlin
1Java's type erasure problem
Java's generics lose type information at runtime due to type erasure, a 2004 backward compatibility decision. While compile-time type checking works, runtime operations like T::class or new T() become impossible. This forces developers to pass Class tokens manually. Kotlin's solution eliminates this boilerplate while maintaining JVM compatibility.
2Inline functions' unique property
The inline keyword causes function bodies to be copied directly into call sites rather than being invoked normally. This eliminates function call overhead for lambdas but also creates an opportunity: the compiler knows the exact concrete types at each call site. The copied code exists in context with full type information before erasure occurs.
3Reified type parameters
When combined with inline, the reified keyword preserves generic type information at runtime. The compiler substitutes concrete types during inlining, making operations like T::class.java possible. This enables elegant APIs like Gson.fromJson T without Class parameters. The solution works because the inlined code exists where type information is still available.
4How viewModels() works
Jetpack's viewModels T delegate demonstrates this pattern perfectly. Without reified, you'd need to pass the Activity class manually. The implementation uses reified T to access the ViewModelProvider internally. This creates cleaner APIs where type information flows naturally without extra ceremony while maintaining full type safety.
5Compilation mechanics
During compilation, Kotlin transforms reified functions by generating specialized versions for each call site. When calling makeInstance User , the compiler creates bytecode as if User::class.java was written directly. This happens after type checking but before JVM bytecode generation, neatly sidestepping erasure limitations.
6Tooling implications
The inlining approach affects code coverage tools like JaCoCo, which may report 0% coverage for inlined functions despite tested logic. This occurs because the original function body disappears during compilation. Developers should recognize this artifact to avoid misinterpreting coverage reports for reified utility functions.
7Performance considerations
While inline functions eliminate call overhead, they increase code size through duplication. The tradeoff makes sense for small, frequently-called utilities but becomes problematic for large functions. Kotlin's standard library carefully balances this, using inline selectively for critical path operations like collection transformations.
8Language design impact
Kotlin's solution demonstrates pragmatic language design - working within JVM constraints while delivering developer experience improvements. The inline+reified combo turns a platform limitation into an implementation detail. This pattern influences newer JVM languages like Kotlin Multiplatform's expect/actual mechanism for cross-platform code.