How Does Kotlin Data Class Generate Methods Internally?

Feb 22, 2026

Purpose

This post demonstrates how Kotlin data class generates methods internally. The key point is understanding the 6 methods the compiler generates and the bitmask strategy for default parameters.

When I write a simple data class in Kotlin:

data class User(val name: String, val age: Int)

I get a lot of generated code for free. But I wanted to understand what the compiler actually creates. So I decompiled the bytecode to see what’s really happening under the hood.

The Six Generated Methods

When I define a data class, the Kotlin compiler generates six methods for me:

Constructor with null checks
equals() - structural equality
hashCode() - hash based on all properties
toString() - string representation
componentN() methods - for destructuring
copy() and copy$default() - for creating modified copies

Let me show you what each looks like in the decompiled bytecode.

1. Constructor with Null Safety

The compiler generates a constructor that includes runtime null checks:

public User(@NotNull String name, int age) {
   Intrinsics.checkNotNullParameter(name, "name");
   this.name = name;
   this.age = age;
}

I can see that Intrinsics.checkNotNullParameter() enforces null safety at runtime. Even though Kotlin has null safety in the type system, this check ensures that null values from Java code are caught immediately.

2. equals() Method

The equals() method implements structural equality:

public boolean equals(Object obj) {
   if (this == obj) return true;
   if (!(obj instanceof User)) return false;
   User other = (User) obj;
   return Intrinsics.areEqual(this.name, other.name)
       && this.age == other.age;
}

I notice the method:

Uses == for reference equality first (fast path)
Checks type with instanceof
Compares each property using Intrinsics.areEqual() which handles nulls
Returns false if any property doesn’t match

This means two data class instances are equal if all their properties are equal.

3. hashCode() Method

The hashCode() implementation uses a standard hash algorithm:

public int hashCode() {
   return (name != null ? name.hashCode() : 0) * 31 + age;
}

I can see the algorithm:

Multiplies by 31 (a prime number that reduces hash collisions)
Uses XOR for combining multiple properties
Handles null properties safely
The order of properties matters for the hash value

This is the same pattern I would write by hand in Java. The compiler just automates it.

4. toString() Method

The toString() method creates a readable string representation:

public String toString() {
   return "User(name=" + this.name + ", age=" + this.age + ")";
}

I get a string in the format ClassName(property=value, ...) which is perfect for debugging. The compiler uses StringBuilder internally for efficient concatenation.

5. componentN() Methods

For each property in the data class, the compiler generates a componentN() method:

public String component1() { return name; }
public int component2() { return age; }

These methods power Kotlin’s destructuring declarations:

val user = User("Alice", 30)
val (name, age) = user
println("$name is $age years old") // Alice is 30 years old

I think of componentN() as indexed getters - component1() for the first property, component2() for the second, and so on.

6. copy() and copy$default() Methods

The compiler generates two copy methods:

// Standard copy method
public User copy(String name, int age) {
   return new User(name, age);
}

// Synthetic method for default parameters
public static User copy$default(User $this, int name, int age, int mask, Object obj) {
   if ((mask & 1) != 0) {
       name = $this.name;
   }
   if ((mask & 2) != 0) {
       age = $this.age;
   }
   return $this.copy(name, age);
}

The standard copy() method is straightforward. But copy$default() is more interesting - it uses a bitmask to track which parameters should use default values.

Understanding the Bitmask Strategy

When I use the copy() method with default parameters:

val user = User("Alice", 30)
val updated = user.copy(age = 31) // name uses default value

The compiler translates this to a call using the bitmask:

User updated = User.copy$default(user, 0, 31, 2, null);

I can break down the bitmask logic:

Each bit represents a parameter position
Bit 0 (value 1) = first parameter (name)
Bit 1 (value 2) = second parameter (age)
The mask 2 means “use default for parameter 1 (name)”

The copy$default() method checks:

if ((mask & 1) != 0) {
    name = $this.name;  // bit 0 set, use default name
}
if ((mask & 2) != 0) {
    age = $this.age;    // bit 1 set, use default age
}

Since my mask is 2 (binary: 10):

(2 & 1) != 0 is false - don’t use default for name
(2 & 2) != 0 is true - use default for age

This bitmask strategy is used throughout Kotlin for all default parameters, not just in data classes. It’s an efficient way to pass default parameter information without creating separate method overloads for every combination.

Bytecode Deep Dive: What Really Gets Created

Let me see the full decompiled Java class for a simple data class:

data class User(val name: String, val age: Int)

When I decompile this to Java, I get about 80 lines of code:

public final class User {
   private final String name;
   private final int age;

   public User(@NotNull String name, int age) {
      Intrinsics.checkNotNullParameter(name, "name");
      this.name = name;
      this.age = age;
   }

   public final String getName() {
      return this.name;
   }

   public final int getAge() {
      return this.age;
   }

   @NotNull
   public User copy(@NotNull String name, int age) {
      Intrinsics.checkNotNullParameter(name, "name");
      return new User(name, age);
   }

   @NotNull
   public static User copy$default(User $this, int name, int age, int mask, Object obj) {
      if ((mask & 1) != 0) {
         name = $this.name;
      }
      if ((mask & 2) != 0) {
         age = $this.age;
      }
      return $this.copy(name, age);
   }

   public String toString() {
      return "User(name=" + this.name + ", age=" + this.age + ")";
   }

   public int hashCode() {
      return (name != null ? name.hashCode() : 0) * 31 + age;
   }

   public boolean equals(Object obj) {
      if (this == obj) return true;
      if (!(obj instanceof User)) return false;
      User other = (User) obj;
      return Intrinsics.areEqual(this.name, other.name) && this.age == other.age;
   }

   public String component1() {
      return this.name;
   }

   public int component2() {
      return this.age;
   }
}

I can see there’s no magic here - it’s just boilerplate code that I would have written myself in Java. The Kotlin compiler saves me from writing this repetitive code, but understanding what it generates helps me use data classes more effectively.

Performance Implications of Data Classes

When I use data classes, I should be aware of the performance costs:

equals() and hashCode() costs:

These methods iterate through all properties
The cost scales with the number of properties
For data classes with many properties, consider overriding equals/hashCode to compare only key fields

data class User(
   val id: String,
   val name: String,
   val email: String,
   val address: String,
   val phone: String
) {
   override fun equals(other: Any?): Boolean {
      if (this === other) return true
      if (other !is User) return false
      return id == other.id  // Compare only ID for performance
   }

   override fun hashCode(): Int {
      return id.hashCode()
   }
}

toString() allocations:

Creates a new String object every time
Avoid calling toString() in hot loops
Consider custom toString() for large objects

Destructuring overhead:

Uses componentN() methods which add method call overhead
Creates temporary variables
For performance-critical code, access properties directly

Common Pitfalls and How to Avoid Them

Mutable Properties Break hashCode Contract

When I use mutable properties in data classes, I can break the hashCode/equals contract:

data class User(var name: String, var age: Int)

val user = User("Alice", 30)
val map = HashMap<User, String>()
map[user] = "admin"

user.age = 31  // MUTATION - changes hashCode!
println(map[user])  // Returns null - can't find the user!

The problem: After mutating age, the hashCode changes. The HashMap can’t find the user because it looks in a different bucket.

Solution: Use immutable properties (val) instead of mutable ones (var):

data class User(val name: String, val age: Int)

val user = User("Alice", 30)
val map = HashMap<User, String>()
map[user] = "admin"

val updated = user.copy(age = 31)  // Create new instance
println(map[user])  // Returns "admin" - original still works
println(map[updated])  // Returns null - different key

Arrays in Data Classes Use Reference Equality

When I include arrays in data classes, equals() uses reference equality:

data class Container(val items: Array<Int>)

val a = Container(arrayOf(1, 2, 3))
val b = Container(arrayOf(1, 2, 3))
println(a == b)  // false! Reference equality for arrays

Solution: Use lists instead of arrays, or override equals:

data class Container(val items: List<Int>)  // List uses structural equality

val a = Container(listOf(1, 2, 3))
val b = Container(listOf(1, 2, 3))
println(a == b)  // true

Circular References Cause Stack Overflow

When data classes reference each other circularly, I can get stack overflow in toString() or equals():

data class Node(val value: Int, val next: Node?)

val list = Node(1, Node(2, Node(3, null)))
println(list)  // Works fine

val cycle = Node(1, Node(2, null))
cycle.next?.next = cycle  // Create cycle
println(cycle)  // StackOverflowError!

Solution: Use lazy properties or override toString/equals:

data class Node(val value: Int, private val _next: Node?) {
   val next: Node? get() = _next  // Accessor instead of constructor

   override fun toString(): String {
      return "Node(value=$value)"  // Don't include next in toString
   }
}

Customizing Generated Methods

Sometimes I want to change how the generated methods work. For example, comparing only business identifiers:

data class User(
   val id: String,
   val name: String,
   val email: String
) {
   override fun equals(other: Any?): Boolean {
      if (this === other) return true
      if (other !is User) return false
      return id == other.id  // Compare only ID
   }

   override fun hashCode(): Int {
      return id.hashCode()
   }
}

This is useful when:

Business logic considers entities equal if they have the same ID
I want to improve performance by avoiding deep comparisons
Some fields shouldn’t participate in equality (e.g., cached values)

Advanced Patterns: Sealed Classes and Value Classes

Data Classes with Sealed Class Hierarchies

I often combine data classes with sealed classes for modeling states:

sealed class Result<out T>
data class Success<T>(val data: T) : Result<T>()
data class Error(val message: String, val code: Int) : Result<Nothing>()
data class Loading(val progress: Int) : Result<Nothing>()

fun handleResult(result: Result<String>) {
   when (result) {
      is Success -> println("Data: ${result.data}")
      is Error -> println("Error ${result.code}: ${result.message}")
      is Loading -> println("Loading: ${result.progress}%")
   }
}

The data class benefits (copy, equals, toString) work within the sealed hierarchy.

Inline Value Classes for Type Safety

I can use value classes with data classes for zero-cost wrappers:

@JvmInline
value class UserId(val value: String)

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

val id1 = UserId("abc")
val id2 = UserId("abc")
println(id1 == id2)  // true - structural equality
println(id1 === id2) // false - different instances at runtime

At runtime, the UserId wrapper is erased, so there’s no performance overhead. But I get type safety at compile time.

Summary

In this post, I showed how Kotlin data class generates methods internally. The key points are:

Six generated methods: Constructor, equals, hashCode, toString, componentN, and copy
No magic: The compiler generates standard Java code that I would write myself
Bitmask strategy: Default parameters use bitmasks to track which values to use
Performance considerations: equals/hashCode scale with property count
Common pitfalls: Mutable properties break hashCode contracts, arrays use reference equality, circular references cause stack overflow
Customization: I can override generated methods when needed

Understanding Kotlin data class internals helps me write better code and debug issues faster. When I know what the compiler generates, I can make informed decisions about when to use data classes versus regular classes.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!