skip to content

How does the Kotlin compiler emit a top-level function on the JVM, and how is it represented in bytecode?

level: middleimportance: must knowfreq 55%

answer

  1. JVM has no free functions — needs a host class
  2. File name + 'Kt' = facade class
  3. Top-level fun → public static method
  4. Kotlin call → invokestatic MyFileKt.fn
  5. javap -p / Show Kotlin Bytecode to inspect

basics

~10 s

The compiler can't put free functions in bytecode, so it creates a hidden class named after the file (e.g. Utils.kt becomes UtilsKt) and makes the function a public static method on that class.

solid answer

~40 s

The JVM has no concept of a function outside a class, so the Kotlin compiler wraps every top-level function from a file into a synthetic class called a **file facade**. The class name is the file name with the extension removed and `Kt` appended: `MathUtils.kt` produces a class `MathUtilsKt`. Each top-level `fun` becomes a `public static` method on that facade. So `square(5)` in Kotlin compiles to `MathUtilsKt.square(5)` in bytecode. Public top-level functions are emitted as `public static`; `private` ones become `private static` and are callable only inside the file. The facade lives in the package declared by the file. This is why Java callers reference top-level functions through the `...Kt` class.

code

kotlin · 12 lines
kotlin
// File: StringUtils.kt
package com.example

fun shout(s: String): String = s.uppercase() + "!"

// Compiles to bytecode equivalent to:
// package com.example;
// public final class StringUtilsKt {
//     public static String shout(String s) { ... }
// }
//
// From Java: StringUtilsKt.shout("hi")

go deeper

for a junior

Knows a hidden class is generated but may not recall the exact naming or static emission.

for a middle

States the FileKt naming rule and that functions become public static methods; can verify with javap.

for a senior

Explains visibility mapping including internal name-mangling and how invokestatic call sites resolve.

for a principal

Reasons about facade stability as a binary-compatibility surface and how renaming files breaks Java callers.

## The problem: the JVM has no free functions The JVM bytecode model only knows **classes and their methods** — there is no such thing as a function that lives outside a class. Kotlin top-level functions therefore need a host class. The compiler generates one automatically: the **file facade class**. ## The naming rule For a file `MathUtils.kt`, the compiler emits a class: ``` MathUtilsKt ``` The rule is: **file name without the `.kt` extension, with `Kt` appended**, placed in the file's declared package. Every top-level `fun` (and top-level `val`/`var` accessor) in that file becomes a **`static`** member of this class. ```kotlin // File: MathUtils.kt package com.example fun square(x: Int): Int = x * x ``` Decompiled, this is roughly: ```java package com.example; public final class MathUtilsKt { public static int square(int x) { return x * x; } } ``` ## How calls compile A Kotlin call `square(5)` becomes an `invokestatic` to `MathUtilsKt.square`. From Kotlin you never see the facade — it is transparent. From **Java**, you must write `MathUtilsKt.square(5)`. ## Visibility mapping - `public` top-level fun → `public static` method on the facade. - `internal` → emitted as `public static` but **name-mangled** (a suffix is added) so it's hard to call from Java by accident, while staying callable within the module. - `private` → `private static`, callable only inside the same file. ## Inspecting it You can verify the facade with the bytecode tools: in IntelliJ, **Tools ▸ Kotlin ▸ Show Kotlin Bytecode** then **Decompile**, or on the command line `javap -p com.example.MathUtilsKt`. ## Why this matters - It explains the `...Kt` names Java interop and stack traces show. - It explains why two files in the same package can't both define `fun foo()` with the same signature only if they collide at link time — actually each file has its own facade, so signatures live in separate classes (no collision across files unless `@JvmName`/multifile facades are used). - It sets up `@JvmName` and `@JvmMultifileClass` (covered separately) which let you rename or merge facades.

  • What class name is generated for a file 'AppConfig.kt'?
    AppConfigKt — the file name minus '.kt' with 'Kt' appended, in the file's package.
  • Is the facade method static or instance?
    Static. Top-level functions become public/private static methods on the synthetic facade class.

saying these in an interview costs you the question

  • Claiming the JVM supports standalone functions natively
  • Saying the facade is named after the package, not the file
  • Forgetting top-level functions become static (not instance) methods
  • Not knowing the 'Kt' suffix convention

context

resolving links…