Wait, does Kotlin just turn into Java code first?

This is a common misconception. When you hit that "Build" button, Kotlin doesn't translate your code into a .java file and then call the Java compiler. That would be incredibly inefficient. Instead, the Kotlin compiler (kotlinc) translates your code directly into JVM bytecode—the same .class files that the Java compiler produces.

I like to think of bytecode as the "universal language" of the JVM. Whether you write in Kotlin, Java, or Scala, the JVM doesn't actually care about the source language. By the time the code reaches the Java Virtual Machine, it's all just a series of opcodes. This is why you can call a Kotlin function from a Java class without any friction; they're both speaking the same bytecode dialect under the hood.

How does the JVM handle things that don't exist in Java, like properties?

You've probably noticed that Kotlin lets you declare a property with a simple val or var. Java doesn't have "properties"—it has fields and methods. So, how does that work in bytecode? The Kotlin compiler performs a bit of "syntactic sugar" for you.

Take this simple class:

class User(val name: String)

If you peek at the bytecode, you'll see that the compiler actually generated a private field for the name and a public "getter" method. It looks roughly like this in Java-equivalent terms:

public final class User {
   private final String name;

   public User(String name) {
      this.name = name;
   }

   public final String getName() {
      return this.name;
   }
}
The JVM sees a field and a method, but you get to write a single line of Kotlin. This keeps the JVM happy while keeping your source code clean.

What happens to top-level functions since the JVM requires everything to be in a class?
This is one of my favorite "magic" tricks the Kotlin compiler pulls. In Kotlin, you can just drop a function into a file without wrapping it in a class. But the JVM is strict: every single method must belong to a class. So, how does Kotlin bypass this?
It creates a hidden "Facade" class. If you have a file named MathUtils.kt with a top-level function called square(), the compiler generates a class called MathUtilsKt (appending "Kt" to the filename).
// In MathUtils.kt
fun square(n: Int): Int = n * n
Under the hood, the bytecode creates something like this:
public final class MathUtilsKt {
   public static final int square(int n) {
      return n * n;
   }
}
When you call square() in Kotlin, the compiler just directs the JVM to call the static method on that generated class. You never see the class, but it's there, doing the heavy lifting.

How can I actually see this bytecode for myself?
You don't need to install some complex reverse-engineering tool to see this. If you're using IntelliJ IDEA, there's a built-in feature that makes this trivial. Go to Tools > Kotlin > Show Kotlin Bytecode.
A panel will open on the right showing the raw bytecode (which looks like assembly language and is, frankly, a headache to read). But here is the pro tip: click the "Decompile" button at the top of that panel. IntelliJ will attempt to turn that bytecode back into readable Java code. It won't be perfect, but it's the best way to understand exactly what the compiler is doing with your Kotlin shortcuts.

📋 Practical Task

Deconstructing a Data Class via Bytecode

In this exercise, you'll explore how Kotlin's data class is expanded during compilation. Follow these steps:

1. Create a new Kotlin file and define a simple data class: data class Product(val id: Int, val price: Double).
2. Use the Show Kotlin Bytecode tool in IntelliJ IDEA to open the bytecode panel.
3. Click Decompile to view the generated Java source.
4. Identify and list the four specific methods the Kotlin compiler automatically generated that you didn't explicitly write in your source code.
5. Compare the equals() method in the decompiled code to a manual implementation you might write in Java. Notice how the compiler handles the null checks and type comparisons for the properties.