How to Fix IntelliJ Kotlin JVM Target Mismatch: 1.8 vs 1.6

By the end of this page, you will understand what a JVM target is in Kotlin and Java projects, why IntelliJ can fail when different modules or compilers use different targets, and how to configure IntelliJ and Gradle so everything compiles consistently.

A JVM target tells the compiler which version of Java bytecode to generate. For example:

• 1.6 generates Java 6 compatible bytecode
• 1.8 generates Java 8 compatible bytecode
• newer values generate newer bytecode formats

This matters because compiled code must be compatible across the whole project. If one part of your Kotlin code is compiled for Java 8 and another part is compiled for Java 6, the compiler may reject operations such as inlining.

In Kotlin, this error often appears when:

• IntelliJ is using one Kotlin compiler target
• Gradle is using a different target
• one module is configured for 1.6 and another for 1.8
• project settings and module settings do not match

The key idea is simple: all related modules should target the same JVM version unless you have a very specific reason not to.

In real programming, build consistency is important because:

• it prevents compile-time incompatibility
• it ensures libraries can work together
• it makes local builds match CI and production builds
• it avoids confusing IDE-only errors

Think of JVM target versions like power plug standards.

• One device is built for a modern socket (1.8)
• Another part expects an older socket (1.6)

Even if both are "electric devices," they may not connect safely.

In the same way, bytecode built for Java 8 may contain features or assumptions that Java 6 bytecode does not support. If IntelliJ tries to combine them during compilation, the build fails.

So the fix is to make sure every part of the project uses the same socket standard: the same JVM target.

In Kotlin, the JVM target is commonly configured in Gradle.

tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile> {
    kotlinOptions {
        jvmTarget = "1.8"
    }
}

Or in older Gradle build files:

compileKotlin {
    kotlinOptions.jvmTarget = "1.8"
}

compileTestKotlin {
    kotlinOptions.jvmTarget = "1.8"
}

In IntelliJ, you may also need to check these settings:

• Project SDK
• Project language level
• Kotlin compiler JVM target
• Module SDK settings

Typical IntelliJ path:

File > Settings > Build, Execution, Deployment > Compiler > Kotlin Compiler

Then set:

Target JVM version: 1.8

You should also check:

File > Project Structure > Project

And confirm:

• Project SDK matches the intended Java version
• Project language level is compatible

Example scenario

Suppose IntelliJ compiles one module with 1.6 and Kotlin compiler settings use 1.8 for another module.

That can trigger:

Cannot inline bytecode built with JVM target 1.8 into bytecode that is being built with JVM target 1.6

Setting both to 1.8 resolves the mismatch.

Consider this situation:

Module A -> compiled with JVM target 1.8
Module B -> compiled with JVM target 1.6

Now imagine Module B uses an inline Kotlin function from Module A.

What happens step by step

1. IntelliJ starts compiling Module B.
2. The Kotlin compiler sees that some code from Module A needs to be inlined.
3. That inlined code was compiled as Java 8 bytecode.
4. But Module B is being compiled as Java 6 bytecode.
5. The compiler refuses, because it cannot safely insert newer bytecode into older output.
6. The build fails with the JVM target mismatch error.

How the fix works

If you change both modules to 1.8:

1. IntelliJ compiles Module A as Java 8 bytecode.
2. IntelliJ compiles Module B as Java 8 bytecode.
3. Inlining is now compatible.
4. The build succeeds.

Practical fix sequence in IntelliJ

1. Open File > Settings.
2. Go to Build, Execution, Deployment > Compiler > Kotlin Compiler.
3. Set Target JVM version to 1.8.
4. Open File > Project Structure.
5. Check Project SDK and Project language level.
6. Check each module under Modules to ensure they use the same SDK.
7. Reimport Gradle if the project uses Gradle.
8. Clean and rebuild the project.

JVM target alignment is important in many real projects:

• Multi-module applications: backend services often have several modules that must compile to the same target.
• Kotlin + Java mixed projects: Java source compatibility and Kotlin JVM target must agree.
• Library projects: if your library targets Java 8, consumers compiling for Java 6 or 7 may hit compatibility problems.
• IDE vs CI builds: local IntelliJ settings may differ from Gradle or CI settings, causing "works on my machine" issues.
• Framework projects: platforms like Corda, Spring, and Android builds often depend on strict build tool consistency.

For a CorDapp project specifically, dependency and plugin versions may expect a certain Java level. If IntelliJ falls back to an older target, the project can fail even when the code itself is correct.

In real codebases, developers usually avoid setting JVM targets only in the IDE. Instead, they keep the source of truth in build files.

Common patterns include:

• Define JVM target in Gradle so every developer gets the same setting.
• Use Gradle import in IntelliJ instead of manually configuring each module.
• Align Java and Kotlin settings:
  • Java sourceCompatibility
  • Java targetCompatibility
  • Kotlin jvmTarget
• Use a single Java toolchain where possible.
• Rebuild after configuration changes to clear stale compiler output.

Example Gradle setup:

plugins {
    id 'org.jetbrains.kotlin.jvm' version '1.9.0'
}

java {
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
}

tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile).configureEach {
    kotlinOptions.jvmTarget = '1.8'
}

This approach is better than relying only on IntelliJ because:

• it is version-controlled
• it works on CI servers
• it prevents per-developer mismatch
• IntelliJ can sync from Gradle automatically

A useful pattern is to treat the IDE as a viewer of build settings, not the main place to define them.

A few mistakes commonly cause this error.

1. Changing IntelliJ settings but not Gradle

If Gradle still says 1.6, IntelliJ may revert or ignore your manual changes.

Broken example:

compileKotlin {
    kotlinOptions.jvmTarget = "1.6"
}

If IntelliJ is set to 1.8 but Gradle uses 1.6, builds may still fail.

Avoid it: update the Gradle config and then reimport the project.

2. Only changing the project SDK

Setting the JDK to Java 8 does not automatically mean Kotlin bytecode target is 1.8.

Avoid it: also set Kotlin compiler target.

3. Forgetting test modules

Sometimes main is configured correctly, but test still uses another target.

Broken example:

compileKotlin {
    kotlinOptions.jvmTarget = "1.8"
}

compileTestKotlin {
    kotlinOptions.jvmTarget = "1.6"
}

Avoid it: align both main and test tasks.

4. Different module settings inside IntelliJ

A multi-module project may have one module using a different SDK.

Avoid it: check all modules in Project Structure.

5. Not rebuilding after the change

Old compiled classes can keep causing confusion.

Avoid it: run a clean rebuild after changing JVM settings.

6. Assuming newer is always safe everywhere

Some older frameworks or plugins require a specific Java version.

Avoid it: match the version recommended by the project or framework, not just the latest one.

Here is how related settings differ:

IntelliJ setting vs Gradle setting

JVM target 1.6 vs 1.8

If your dependencies are built for 1.8, your project should usually target at least 1.8 too.

Problem:
Cannot inline bytecode built with JVM target 1.8 into bytecode that is being built with JVM target 1.6

Quick fix in IntelliJ

1. File > Settings
2. Build, Execution, Deployment > Compiler > Kotlin Compiler
3. Set Target JVM version to 1.8
4. File > Project Structure
5. Set Project SDK to Java 8
6. Check all modules use the same SDK
7. Reimport Gradle
8. Clean and rebuild

Preferred fix in Gradle

java {
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
}

tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile).configureEach {
    kotlinOptions.jvmTarget = '1.8'
}

Key rule

• Java version used by the project
• Kotlin jvmTarget
• Java targetCompatibility
• module settings

should all be aligned.

Common cause

• IntelliJ uses one target
• Gradle uses another target
• one module is still on 1.6

Good habit

Store JVM target settings in version-controlled build files, not only in the IDE.

Why does Kotlin mention bytecode in this error?

Kotlin compiles to JVM bytecode. If different parts of the project generate incompatible bytecode versions, the compiler reports it.

Is setting the Project SDK enough to fix this?

No. The Project SDK selects the JDK, but Kotlin also has its own jvmTarget setting.

Should I change IntelliJ or Gradle?

Usually both should match, but Gradle should be the main source of truth for team projects.

Why does this happen when opening an older project?

Older projects may default to Java 6 or Java 7 settings, while newer dependencies are compiled for Java 8.

What JVM target should I use?

Use the version required by the project and its dependencies. For many Kotlin/JVM projects, 1.8 is a common minimum.

Do I need to check every module?

Yes. In multi-module projects, one module with a different target can trigger this error.

Can cached build files cause the error to continue?

Yes. After updating settings, clean and rebuild the project to remove old compiled output.

• Kotlin compiler options — includes jvmTarget and other settings that affect generated bytecode.
• Java SDK vs JRE — helps explain what IntelliJ uses to compile and run code.
• Gradle build configuration — important because JVM target is often defined there.
• Project SDK and module SDK in IntelliJ — relevant because mismatched module settings can cause build issues.
• Java bytecode compatibility — explains why code compiled for one target may not work with another.
• Kotlin inline functions — closely related because the error specifically mentions inlining.
• sourceCompatibility and targetCompatibility — Java-side settings that should align with Kotlin.
• Multi-module project configuration — useful because different modules often introduce version mismatches.