Question
Understanding the Kotlin Plugin Version Warning in Gradle for Android and Java Modules
Question
In an Android Studio project, I added a Java library module named core. The project uses Kotlin in both the app module and the library module. My Gradle files are configured like this:
// project/build.gradle
buildscript {
ext.kotlin_version = '1.2.40'
repositories {
google()
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:3.0.1'
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
}
}
allprojects {
repositories {
google()
jcenter()
}
}
task clean(type: Delete) {
delete rootProject.buildDir
}
// core/build.gradle
apply plugin: 'java-library'
apply plugin: 'kotlin'
dependencies {
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7"
// ...
}
// app/build.gradle
apply plugin: 'com.android.application'
apply plugin: 'kotlin-android'
apply plugin: 'kotlin-android-extensions'
android {
// ...
}
dependencies {
implementation project(':core')
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
implementation 'com.android.support.constraint:constraint-layout:1.1.0'
implementation 'com.android.support:appcompat-v7:27.1.1'
androidTestImplementation 'com.android.support.test:runner:1.0.1'
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.1'
testImplementation 'junit:junit:4.12'
}
In core/build.gradle, Android Studio shows this warning for the Kotlin standard library dependency:
Plugin version (1.2.40) is not the same as library version (jdk7-1.2.40)
I tried several forms of the dependency, including:
implementation "org.jetbrains.kotlin:kotlin-stdlib"
implementation "org.jetbrains.kotlin:kotlin-stdlib:1.2.40"
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.2.40"
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
implementation "org.jetbrains.kotlin:kotlin-stdlib-jre7:$kotlin_version"
The project builds successfully, but I want to understand why the warning appears and how to remove it correctly instead of just ignoring or suppressing it. I am using Android Studio 3.0.1.
Short Answer
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.
Concept
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-stdlibkotlin-stdlib-jdk7kotlin-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.
Mental Model
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.
Syntax and Examples
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_versionproperty
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.
Step by Step Execution
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
- Gradle reads
ext.kotlin_version = '1.2.40'. - Gradle uses that value to load the Kotlin Gradle plugin:
org.jetbrains.kotlin:kotlin-gradle-plugin:1.2.40
- In the
coremodule, Gradle reads:org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.2.40
- The build system sees the library version as
1.2.40. - Android Studio runs an inspection to compare plugin and library versions.
- In some old tool versions, that inspection incorrectly interprets the artifact and reports:
jdk7-1.2.40
- 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.
Real World Use Cases
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.
Real Codebase Usage
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.
Common Mistakes
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
Comparisons
| Topic | What it does | Example | Notes |
|---|---|---|---|
| Kotlin Gradle plugin | Compiles Kotlin during the build | org.jetbrains.kotlin:kotlin-gradle-plugin:1.2.40 | Build-time tool |
| Kotlin stdlib | Runtime library used by Kotlin code | org.jetbrains.kotlin:kotlin-stdlib:1.2.40 | Needed by Kotlin code |
kotlin-stdlib-jdk7 | Stdlib with JDK 7 extensions | org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.2.40 | Common in older setups |
| IDE inspection | Checks for possible mismatches | Warning in editor | Can be wrong |
| Gradle build resolution | Actually resolves and builds dependencies |
Cheat Sheet
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
- Check the plugin version in root
build.gradle. - Check the stdlib version in every module.
- Sync Gradle.
- Rebuild the project.
- If the build succeeds and versions truly match, it is likely an IDE inspection issue.
- 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"
FAQ
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.
Mini Project
Description
Create a small multi-module Gradle project with one app module and one shared library module, both using Kotlin. The goal is to practice keeping Kotlin plugin and stdlib versions aligned and to learn how to verify whether a warning is real or just an IDE issue.
Goal
Set up consistent Kotlin versioning across modules and confirm the project builds without real dependency mismatches.
Requirements
- Define one shared Kotlin version in the root Gradle file.
- Apply the appropriate Kotlin plugin in both modules.
- Add the Kotlin standard library to both modules using the same shared version.
- Make the app module depend on the library module.
- Build the project and verify that Gradle resolves the same Kotlin version everywhere.
Keep learning
Related questions
Accessing Kotlin Extension Functions from Java
Learn how Kotlin extension functions are compiled and how to call them correctly from Java with clear examples and common pitfalls.
Android AlarmManager Example: Scheduling Tasks with AlarmManager
Learn how to use Android AlarmManager to schedule tasks, set alarms, and handle broadcasts with a simple beginner example.
Android Foreground Service Notification Channels in Kotlin
Learn why startForeground fails on Android 8.1 and how to create a valid notification channel for foreground services in Kotlin.