Understanding the Kotlin Plugin Version Warning in Gradle for Android and Java Modules

By the end of this page, you will understand how Kotlin plugin and library version checks work in Gradle, why Android Studio can show a false mismatch warning, and how to keep Kotlin dependencies consistent across Android and Java modules.

Kotlin projects usually have two related but different versioned pieces:

• the Kotlin Gradle plugin, which Gradle uses to compile Kotlin code
• the Kotlin standard library, which your application or library uses at runtime

These versions are usually expected to match. For example:

• plugin: 1.2.40
• library: 1.2.40

However, Kotlin library artifact names can include platform suffixes such as:

• kotlin-stdlib
• kotlin-stdlib-jdk7
• kotlin-stdlib-jdk8

In older Android Studio and Kotlin plugin combinations, the IDE inspection that checks versions could misread the dependency notation. Instead of comparing only the version number 1.2.40, it incorrectly interpreted part of the artifact name and displayed something like:

• plugin version: 1.2.40
• library version: jdk7-1.2.40

That is not a real semantic version mismatch. It is an IDE warning issue, not necessarily a Gradle build problem.

Why this matters:

• Real Kotlin version mismatches can cause compiler or runtime issues.
• False warnings can confuse you and make build files look broken when they are actually correct.
• Understanding the difference helps you decide whether to fix configuration, update tooling, or safely ignore an IDE-only inspection.

Think of the Kotlin plugin and Kotlin library like two labels on related boxes:

• Box 1: the compiler tools used during the build
• Box 2: the runtime library included in your project

Normally, both boxes should have the same number on them, such as 1.2.40.

Now imagine a scanner that reads the label on Box 2 incorrectly. Instead of reading only 1.2.40, it reads jdk7-1.2.40 because it accidentally combines part of the product name with the version.

The boxes still match in reality. The scanner is just misreporting what it sees.

That is what happened here: Gradle is fine, but the IDE inspection is likely parsing the dependency incorrectly.

The usual pattern in Gradle is to define the Kotlin version once and reuse it everywhere.

// Root build.gradle
buildscript {
    ext.kotlin_version = '1.2.40'
    dependencies {
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}

Then use the same version in modules:

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

Example: consistent Kotlin setup

// core/build.gradle
apply plugin: 'java-library'
apply plugin: 'kotlin'

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

This is correct because:

• the module applies the Kotlin plugin
• the module includes the Kotlin standard library
• the version comes from the shared kotlin_version property

Better consistency across modules

// app/build.gradle
dependencies {
    implementation project(':core')
    implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
}

Using the same variable in every module reduces mistakes.

Important note

If Android Studio still shows the warning even when the versions match, especially in older versions, the issue is often the IDE inspection rather than your Gradle configuration.

Consider this simplified setup:

// Root build.gradle
buildscript {
    ext.kotlin_version = '1.2.40'
    dependencies {
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}

// core/build.gradle
dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
}

What happens step by step

1. Gradle reads ext.kotlin_version = '1.2.40'.
2. Gradle uses that value to load the Kotlin Gradle plugin:
   • org.jetbrains.kotlin:kotlin-gradle-plugin:1.2.40
3. In the core module, Gradle reads:
   • org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.2.40
4. The build system sees the library version as 1.2.40.
5. Android Studio runs an inspection to compare plugin and library versions.
6. In some old tool versions, that inspection incorrectly interprets the artifact and reports:
   • jdk7-1.2.40
7. The IDE shows a warning, even though Gradle can resolve and build the project correctly.

Key takeaway

The build process and the IDE inspection are not exactly the same thing. A warning shown in the editor is sometimes based on IDE parsing logic rather than actual Gradle resolution.

This concept appears often in real projects whenever build tools, plugins, and libraries all have versions.

Common situations

• Android apps with multiple modules

  • One module is an app, another is a Java or Kotlin library.
  • Shared Kotlin versions must stay aligned.

• Backend Kotlin projects

  • Kotlin compiler plugin version should match the stdlib version used by modules.

• Large Gradle builds

  • Teams centralize versions in root properties or version catalogs.
  • IDE warnings can appear if one module is configured differently.

• Tool upgrade periods

  • Upgrading Android Studio, Kotlin plugin, or Gradle can temporarily create false warnings or stale inspections.

Why developers care

• Real mismatches can break builds.
• False positives waste debugging time.
• Clean version management makes builds easier to maintain.

In real codebases, developers usually manage Kotlin versions with a few common patterns.

1. Single source of truth

Keep the Kotlin version in one place:

ext.kotlin_version = '1.2.40'

Then reuse it everywhere.

2. Consistent dependency declarations

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

This avoids one module drifting to another version.

3. Upgrade tooling when warnings look suspicious

If the build works but the IDE reports nonsense, developers often:

• sync Gradle again
• invalidate caches / restart IDE
• upgrade Android Studio
• upgrade the Kotlin plugin

4. Prefer modern conventions in newer projects

In modern Android/Kotlin projects, you often rely on newer plugin versions and simplified stdlib handling, which reduces these older inspection issues.

5. Validate with Gradle, not only the editor

Developers trust:

• ./gradlew build
• dependency reports
• resolved versions

more than an IDE hint when the two disagree.

That is an important professional habit: IDE warnings are useful, but the build is the source of truth.

1. Assuming every warning means the build is truly wrong

Sometimes the warning is from the IDE, not Gradle.

Example

implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"

If this builds correctly, the dependency itself may be fine.

2. Hardcoding versions in one module but not others

Broken pattern:

// app/build.gradle
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.2.40"

// core/build.gradle
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.2.31"

Avoid this by reusing one shared version variable.

3. Omitting the version and expecting every tool to interpret it well

This can work if dependency management supplies the version, but it can also confuse older inspections.

implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7"

Safer for clarity:

implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"

4. Mixing old artifact names without understanding them

Older Kotlin versions used names like jre7; later versions prefer jdk7.

If you switch names randomly while troubleshooting, you can create more confusion.

5. Debugging only the dependency line

Quick reference

Define Kotlin version once

buildscript {
    ext.kotlin_version = '1.2.40'
}

Apply Kotlin plugin

apply plugin: 'kotlin'

For Android modules:

apply plugin: 'kotlin-android'

Add Kotlin stdlib

implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"

Rules to remember

• Plugin version and stdlib version should usually match.
• Use one shared version variable across modules.
• A successful Gradle build is more trustworthy than a suspicious IDE warning.
• Older Android Studio versions may show false mismatch warnings.

If you see a mismatch warning

1. Check the plugin version in root build.gradle.
2. Check the stdlib version in every module.
3. Sync Gradle.
4. Rebuild the project.
5. If the build succeeds and versions truly match, it is likely an IDE inspection issue.
6. Update Android Studio/Kotlin plugin if possible.

Common dependency forms

implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version"

Why does Android Studio say the Kotlin plugin version does not match the library version?

In older tooling, the IDE inspection could parse kotlin-stdlib-jdk7 incorrectly and treat part of the artifact name as if it were part of the version.

Is jdk7-1.2.40 a real Kotlin version?

No. The real version is 1.2.40. The jdk7 part belongs to the artifact name, not the version number.

If the project builds successfully, can I ignore the warning?

If you verified that the plugin and library versions truly match, then yes, it is often safe to treat it as an IDE-only warning.

How do I properly remove the warning?

First make sure all Kotlin dependencies use the same version variable. Then try Gradle sync, IDE restart, cache invalidation, or upgrading Android Studio and the Kotlin plugin.

Should I use kotlin-stdlib or kotlin-stdlib-jdk7?

In older projects, kotlin-stdlib-jdk7 was common. The correct choice depends on project setup and Kotlin version, but the warning you saw is not caused by using a valid stdlib artifact by itself.

Why does it happen in one module but not another?

Different module types, plugin applications, or IDE inspections can behave differently. A Java library module using the Kotlin plugin may trigger the inspection differently than the Android app module.

Is this a Gradle problem or an Android Studio problem?

If Gradle builds successfully and versions match, it is most likely an Android Studio or Kotlin IDE inspection issue.

• Gradle dependency management — Related because Kotlin versions are declared and resolved through Gradle.
• Android multi-module projects — Related because version consistency often matters across app and library modules.
• Kotlin standard library — Related because the warning is specifically about stdlib artifacts.
• Kotlin Gradle plugin — Related because the plugin version is being compared against library versions.
• Build tools vs IDE inspections — Related because the warning may come from the IDE, not the actual build system.
• Dependency version alignment — Related because keeping versions consistent prevents real compatibility problems.
• Android Studio Gradle sync — Related because sync issues can cause stale or misleading warnings.