skip to content

Kotlin/JVM Target

3 roadmaps5 questions

The jvm target compiles to ordinary bytecode with full access to the Java ecosystem, with the toolchain and jvmTarget settings controlling the bytecode level. It is the familiar case and the baseline everything else is compared against.

part ofKotlinoverview, primer and where to startread it →
on this pageshow

explore

questions

5

In a Kotlin Multiplatform build, what does declaring the jvm() target do, and what kind of artifacts does it produce?

level: juniorimportance: must knowfreq 60%

answer

  1. jvm() in the kotlin { } block
  2. produces .class bytecode -> .jar
  3. full java.* / javax.* access
  4. creates jvmMain / jvmTest source sets
  5. tasks: jvmJar, jvmTest, compileKotlinJvm

basics

~10 s

Adding jvm() tells the compiler to build a JVM version of your code. It produces Java bytecode (.class files, usually packaged in a .jar) that runs on any Java Virtual Machine.

solid answer

~40 s

In a Kotlin Multiplatform (KMP) project, calling jvm() inside the kotlin { } block registers the JVM compilation target. The Kotlin/JVM backend then compiles your common code plus the jvmMain source set into JVM bytecode — .class files packaged into a .jar. This artifact runs on any JVM and has full access to the java.* standard library and any JVM dependency (Spring, JDBC, etc.). The target creates source sets like jvmMain and jvmTest and Gradle tasks such as jvmJar and jvmTest. It contrasts with native(), js(), or wasm() targets, which compile the same common code to other backends. jvm() is the most mature, fastest-compiling target and the natural choice for server-side or desktop JVM code.

code

kotlin · 9 lines
kotlin
kotlin {
    jvm()
    sourceSets {
        commonMain.dependencies { /* shared deps */ }
        jvmMain.dependencies {
            implementation("com.squareup.okhttp3:okhttp:4.12.0") // a JVM lib
        }
    }
}

go deeper

for a junior

Knows jvm() makes a JVM build that produces bytecode/.jar runnable on a JVM.

for a middle

Explains source sets (jvmMain/jvmTest), full java.* access, and how common code is shared.

for a senior

Contrasts jvm() with native/js/wasm backends and explains why it's the mature default for server code.

for a principal

Discusses positioning the JVM target in a multi-target architecture and what belongs in common vs jvmMain for portability.

## What is the Kotlin/JVM target Kotlin is a multi-backend language: the same source can be compiled to JVM bytecode, native machine code, JavaScript, or WebAssembly. In a **Kotlin Multiplatform (KMP)** project you declare which backends you want inside the `kotlin { }` block of `build.gradle.kts`. The `jvm()` function registers the **JVM target**. ```kotlin kotlin { jvm() // compile to JVM bytecode // native(), js(), wasmJs() would add other backends sourceSets { val commonMain by getting val jvmMain by getting // JVM-only code lives here } } ``` ## What it produces - The Kotlin/JVM compiler backend translates your Kotlin into **JVM bytecode**: `.class` files, one (or more) per class. - These are bundled by the `jvmJar` task into a **`.jar`** archive — the standard Java library/application format. - The result runs on **any Java Virtual Machine** of a compatible version. ## What you get access to - The **`java.*`** and **`javax.*`** standard libraries (collections, IO, NIO, concurrency, reflection). - Any JVM dependency on the classpath — Spring, Hibernate, JDBC drivers, OkHttp, etc. - Java interop: you can call Java from Kotlin and Kotlin from Java seamlessly. ## Source sets and tasks Declaring `jvm()` automatically creates: - Source sets **`jvmMain`** (production) and **`jvmTest`** (tests), which depend on `commonMain`/`commonTest`. - Gradle tasks like **`jvmJar`**, **`jvmTest`**, and **`compileKotlinJvm`**. Common code in `commonMain` is shared across all targets; platform-specific JVM code goes in `jvmMain` and can use `actual` implementations for `expect` declarations. ## Why choose it The JVM target is the **oldest and most mature** Kotlin backend, with the fastest compile times and the broadest ecosystem. It is the default choice for server-side services, build tooling, and desktop apps.

  • Where does code that calls java.io.File go — commonMain or jvmMain?
    jvmMain. commonMain must compile for all targets, so it cannot reference java.* APIs; JVM-specific code belongs in jvmMain.
  • What Gradle task packages the JVM output?
    jvmJar, which assembles the compiled .class files into a .jar archive.

jvm() is like choosing the JVM as the 'language' your shared Kotlin recipe is translated into so it can run on any Java machine.

saying these in an interview costs you the question

  • Saying jvm() produces native machine code or an executable binary
  • Thinking common code can freely call java.* APIs
  • Confusing the JVM target with the Android target
  • Believing a .jar runs without any JVM installed

context

resolving links…

open as a page

What is the difference between jvmToolchain(...) and compilerOptions.jvmTarget, and how do they interact?

level: middleimportance: must knowfreq 55%

basics

~10 s

jvmToolchain picks which JDK version actually compiles and runs your code. jvmTarget sets the bytecode version the compiler emits. The toolchain is the tool; jvmTarget is the output format.

open as a page

Explain the source-set layout that the jvm() target adds to a KMP module and where JVM-only code that uses java.* APIs must live.

level: middleimportance: should knowfreq 45%

basics

~10 s

jvm() adds jvmMain and jvmTest source sets that build on top of commonMain/commonTest. Any code touching java.* APIs must go in jvmMain because common code has to compile for every target.

open as a page

Your KMP service must run on a production JVM 17 fleet but you want to build with the latest JDK. How do you configure the jvm() target, and what risks arise from getting the bytecode level wrong?

level: seniorimportance: should knowfreq 35%

basics

~10 s

Pin jvmTarget to JVM_17 so the bytecode loads on JVM 17, while using a newer JDK toolchain to compile. If bytecode is too new, production throws UnsupportedClassVersionError at load time.

open as a page

How does the Kotlin/JVM target represent Kotlin features in bytecode so that Java callers can use them, and what annotations control this?

level: seniorimportance: should knowfreq 40%

basics

~10 s

Kotlin compiles to ordinary JVM bytecode, so Java can call it. Annotations like @JvmStatic, @JvmName, @JvmOverloads, and @JvmField adjust how Kotlin constructs appear to Java callers.

open as a page