How to Fix Kotlin Runtime JAR Version Mismatch Warnings

By the end of this page, you will understand what a Kotlin runtime version mismatch warning means, why it happens, how dependencies can bring in older Kotlin JARs transitively, and how to fix the problem in a Gradle-based Kotlin project by aligning Kotlin library versions explicitly.

When you compile or run a Kotlin project, several Kotlin runtime libraries may appear on the classpath, such as:

• kotlin-stdlib
• kotlin-reflect
• kotlin-runtime (older setups)
• other Kotlin-related artifacts

These libraries are expected to use compatible versions. If your project uses Kotlin 1.1, but one dependency brings in Kotlin 1.0.6, Gradle may place both on the classpath. That leads to a warning like:

Kotlin runtime JAR files in the classpath should have the same version

This matters because:

• Kotlin compiler plugins and runtime libraries are designed to work together.
• Mixing versions can cause subtle bugs.
• Reflection support may fail or behave unexpectedly.
• Build output becomes harder to reason about.

Yes, this warning is often caused by a transitive dependency. A library you added may depend on an older Kotlin runtime, and Gradle includes it automatically unless you override or exclude it.

A common fix is to declare the Kotlin libraries explicitly in your build so Gradle resolves them all to the same version.

Think of your application like a team using instruction manuals.

• kotlin-stdlib is the basic manual everyone uses.
• kotlin-reflect is a more advanced manual for reflection features.
• Your Kotlin compiler version is the trainer teaching from a specific edition.

If half the team has the 1.1 manual and another part has the 1.0.6 manual, people may follow different instructions. Even if things mostly work, confusion appears.

The fix is simple: make sure everyone uses the same edition of the manual.

In Gradle, the usual fix is to set one Kotlin version and use it consistently.

Groovy DSL example

buildscript {
    ext.kotlin_version = '1.1.0'
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}

apply plugin: 'kotlin'

repositories {
    mavenCentral()
}

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
    implementation "org.jetbrains.kotlin:kotlin-reflect:$kotlin_version"
}

Kotlin DSL example

plugins {
    kotlin("jvm") version "1.1.0"
}

repositories {
    mavenCentral()
}

dependencies {
    implementation(kotlin("stdlib"))
    implementation(kotlin("reflect"))
}

Why this helps

By explicitly declaring kotlin-reflect and kotlin-stdlib, you reduce the chance that Gradle will silently use an older transitive version.

Finding the source of the old version

In Gradle, inspect the dependency tree:

gradle dependencies

Or inspect one specific dependency:

gradle dependencyInsight --dependency kotlin-stdlib --configuration compileClasspath

This shows which library is bringing in the old Kotlin artifact.

Consider this dependency setup:

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:1.1.0"
    implementation "com.example:some-library:2.0"
}

Assume some-library depends on:

org.jetbrains.kotlin:kotlin-stdlib:1.0.6

What happens step by step

1. Your project requests kotlin-stdlib:1.1.0.
2. some-library requests kotlin-stdlib:1.0.6.
3. Gradle resolves dependencies for the classpath.
4. If related Kotlin artifacts are not aligned, you may end up with a mixed Kotlin runtime set.
5. The Kotlin tooling detects that Kotlin runtime JAR versions do not match.
6. You see the warning.

Example of making versions explicit

ext.kotlin_version = '1.1.0'

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
    implementation "org.jetbrains.kotlin:kotlin-reflect:$kotlin_version"
}

Then verify

Run:

gradle dependencies

Look for all org.jetbrains.kotlin artifacts and confirm they use the same version.

Version alignment issues happen often in real projects.

Library-based applications

A project may depend on several third-party libraries, and one of them may still use an old Kotlin version.

Spring or server applications

Backend apps often include many transitive dependencies. If Kotlin support is added later, runtime JAR mismatches can appear.

Android projects

Android builds frequently combine plugins, support libraries, and Kotlin artifacts. Version drift is common if dependencies are not managed centrally.

Multi-module builds

One module may use a newer Kotlin plugin while another still references older Kotlin runtime artifacts.

In real codebases, developers usually avoid this warning by centralizing version management.

Common patterns

• Define one Kotlin version in a shared place.
• Reuse that version for plugin and dependencies.
• Add explicit Kotlin runtime dependencies when needed.
• Inspect dependency graphs when warnings appear.
• Exclude unwanted transitive Kotlin dependencies from third-party libraries.

Example: exclude an old transitive Kotlin dependency

implementation("com.example:some-library:2.0") {
    exclude group: "org.jetbrains.kotlin", module: "kotlin-stdlib"
}

Then add the correct version yourself:

implementation "org.jetbrains.kotlin:kotlin-stdlib:1.1.0"
implementation "org.jetbrains.kotlin:kotlin-reflect:1.1.0"

Another common pattern: force a version

configurations.all {
    resolutionStrategy.eachDependency { details ->
        if (details.requested.group == 'org.jetbrains.kotlin') {
            details.useVersion '1.1.0'
        }
    }
}

This is useful when several libraries pull different Kotlin versions.

Here are common mistakes beginners make when fixing this warning.

1. Updating only the plugin, not the runtime libraries

Broken example:

buildscript {
    ext.kotlin_version = '1.1.0'
}

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:1.0.6"
}

Why it is wrong:

• The compiler plugin and runtime are still mismatched.

Fix:

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:1.1.0"
}

2. Ignoring transitive dependencies

A project may look correct at the top level, but a library can still pull older Kotlin JARs.

How to avoid it:

• Run gradle dependencies
• Use dependencyInsight
• Exclude or override old Kotlin artifacts

3. Declaring kotlin-reflect without a version strategy

Broken example:

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:1.1.0"
    implementation "org.jetbrains.kotlin:kotlin-reflect:1.0.6"
}

Fix:

def kotlinVersion = '1.1.0'

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlinVersion"
    implementation "org.jetbrains.kotlin:kotlin-reflect:$kotlinVersion"
}

kotlin-stdlib vs kotlin-reflect

// Keep one shared Kotlin version
ext.kotlin_version = '1.1.0'

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
    implementation "org.jetbrains.kotlin:kotlin-reflect:$kotlin_version"
}

Useful commands

gradle dependencies
gradle dependencyInsight --dependency kotlin-stdlib --configuration compileClasspath
gradle dependencyInsight --dependency kotlin-reflect --configuration compileClasspath

Key rules

• Kotlin runtime JARs should use the same version.
• A third-party library can pull an old Kotlin version transitively.
• Explicitly declare Kotlin libraries when needed.
• Exclude or override old Kotlin dependencies if necessary.
• Keep the Kotlin plugin version aligned with runtime libraries.

Common Kotlin artifacts

• kotlin-stdlib
• kotlin-reflect
• kotlin-runtime (older setups)

Typical fixes

• Add explicit kotlin-reflect
• Align all Kotlin dependency versions
• Inspect the Gradle dependency tree
• Exclude outdated transitive Kotlin artifacts

Why does Gradle include an older Kotlin version if I did not add it directly?

Because one of your dependencies may include it transitively.

What does “make kotlin-reflect explicit” mean?

It means you should declare kotlin-reflect directly in your dependencies with the version you want, instead of relying on an indirect dependency.

Can a Kotlin version mismatch break my app?

Yes. Sometimes it only shows a warning, but it can also lead to runtime or reflection-related problems.

How do I find which library brings in 1.0.6?

Use Gradle dependency inspection commands such as gradle dependencies or gradle dependencyInsight.

Should all org.jetbrains.kotlin dependencies use the same version?

In general, yes. Keeping them aligned is the safest approach.

Is excluding transitive Kotlin dependencies safe?

Usually yes, if you add the correct version back explicitly. But exclusions should be tested carefully.

Do I always need kotlin-reflect?

No. Only add it if your project or one of your libraries uses Kotlin reflection features.

• Gradle dependency management — Helps you understand how direct and transitive dependencies are resolved.
• Transitive dependencies — Explains how a library can silently bring in other libraries.
• Kotlin standard library — Core runtime library often involved in version mismatch warnings.
• Kotlin reflection — Relevant when the warning mentions kotlin-reflect.
• Dependency resolution strategy — Useful for forcing consistent versions across a project.
• Build classpath — Important for understanding where JAR conflicts come from.