FR
RU
EN
ES
ZH
DE
PT
AR
HI
Introduction : Le triangle jaune familier
\nAvez-vous déjà vu cet avertissement dans IntelliJ IDEA ou lors de la compilation Gradle ? Il apparaît, vous vérifiez build.gradle.kts — et vous voyez que les versions correspondent. Mais l'IDE continue obstinément à surligner avec un triangle jaune : "Kotlin plugin version is not the same as library version". Familier ?
C'est l'un des problèmes les plus populaires sur Stack Overflow (des milliers de vues !). Il semble que le système soit devenu fou. Mais en réalité, il y a une raison technique bien précise derrière cela. Dans cet article, nous ne nous contenterons pas de supprimer cet avertissement agaçant, mais nous comprendrons également comment il affecte l'optimisation et les performances de votre projet Kotlin.
\n\nLe cœur du problème : Pourquoi l'avertissement apparaît-il si les versions correspondent ?
\nAnalysons l'anatomie de l'erreur. Vous écrivez dans build.gradle.kts :
plugins {\n kotlin("jvm") version "1.9.22" apply false\n}\n\n// Dans la section dependencies :\nimplementation(kotlin("stdlib", "1.9.22"))\nTout semble correct. Mais Gradle voit deux artefacts différents :
\n- \n
- Kotlin Gradle Plugin — version 1.9.22 (gère la compilation) \n
- Kotlin Stdlib — version 1.9.22 (bibliothèque d'exécution) \n
Le problème est que Gradle peut attirer une dépendance transitive avec une version différente de Kotlin. Par exemple, si votre projet utilise la bibliothèque Fuel ou Ktor, elles peuvent entraîner kotlin-stdlib:1.8.0. En conséquence, le classpath contient deux versions différentes d'une même bibliothèque.
L'IDE voit un conflit de versions entre le plugin (1.9.22) et l'une des bibliothèques (1.8.0) — et émet un avertissement. Pendant ce temps, votre dépendance explicite kotlin("stdlib", "1.9.22") peut être remplacée par la dépendance transitive.
Diagnostic : Comment trouver le coupable ?
\nAvant de traiter, il faut comprendre d'où vient l'ancienne version. Utilisez les outils intégrés de Gradle.
\n\nMéthode 1 : La tâche Gradle dependencies
\nExécutez dans le terminal :
\n./gradlew dependencies --configuration runtimeClasspathDans la sortie, recherchez les lignes contenant kotlin-stdlib. Vous verrez quelque chose comme :
+--- org.jetbrains.kotlin:kotlin-stdlib:1.9.22\n| \\--- org.jetbrains.kotlin:kotlin-stdlib-common:1.9.22\n+--- com.example:some-library:2.0.0\n| \\--- org.jetbrains.kotlin:kotlin-stdlib:1.8.0 -> 1.9.22\nLa flèche -> montre que Gradle a résolu le conflit en faveur de la version 1.9.22. Mais l'avertissement peut tout de même persister si le plugin analyse les versions d'origine.
Méthode 2 : IntelliJ IDEA — Module Settings
\nOuvrez File → Project Structure → Modules. Sélectionnez votre module et regardez l'onglet Dependencies. Toutes les dépendances y sont affichées, y compris les transitives. Si vous voyez kotlin-stdlib:1.8.0 (ou une autre version) — c'est la source du problème.
4 méthodes pour corriger l'avertissement (et améliorer les performances)
\nPassons maintenant à la partie la plus intéressante — les solutions. Chaque méthode affecte l'optimisation de la compilation et les performances d'exécution.
\n\nMéthode 1 : Alignement forcé des versions (Alignment)
\nL'approche la plus correcte est d'utiliser Kotlin BOM (Bill of Materials). Cela garantit que toutes les dépendances Kotlin seront de la même version.
\n// build.gradle.kts\ndependencies {\n implementation(platform("org.jetbrains.kotlin:kotlin-bom:1.9.22"))\n implementation("org.jetbrains.kotlin:kotlin-stdlib")\n // Maintenant, il n'est plus nécessaire de spécifier la version — elle est prise du BOM\n}\nPourquoi est-ce bon pour les performances ? Le BOM élimine la duplication des classes dans le classpath. Si vous avez deux versions de kotlin-stdlib
Blogs
Book Recommendations
Lire aussi
