Kotlin-плагин и библиотека: ложная тревога версий

Онлайн-тренажер Python для начинающих

Изучайте Python легко и без перегрузки теорией. Решайте практические задачи с автоматической проверкой, получайте подсказки на русском языке и пишите код прямо в браузере — без необходимости что-либо устанавливать.

Начать курс

Вступление: Знакомый жёлтый треугольник

Вы когда-нибудь видели это предупреждение в IntelliJ IDEA или при сборке Gradle? Оно появляется, вы проверяете build.gradle.kts — и видите, что версии совпадают. Но IDE упорно продолжает подсвечивать жёлтым треугольником: "Kotlin plugin version is not the same as library version". Знакомо?

Это одна из самых популярных проблем на Stack Overflow (тысячи просмотров!). Кажется, что система сошла с ума. Но на самом деле за этим кроется вполне конкретная техническая причина. В этой статье мы не просто уберём надоедливый warning, но и поймём, как он влияет на оптимизацию и производительность вашего Kotlin-проекта.

Суть проблемы: Почему warning возникает, если версии совпадают?

Давайте разберём анатомию ошибки. Вы пишете в build.gradle.kts:

plugins {
    kotlin("jvm") version "1.9.22" apply false
}

// В секции dependencies:
implementation(kotlin("stdlib", "1.9.22"))

Вроде бы всё честно. Но Gradle видит два разных артефакта:

  • Kotlin Gradle Plugin — версия 1.9.22 (управляет компиляцией)
  • Kotlin Stdlib — версия 1.9.22 (библиотека времени выполнения)

Проблема в том, что Gradle может притянуть транзитивную зависимость с другой версией Kotlin. Например, если ваш проект использует библиотеку Fuel или Ktor, они могут тянуть за собой kotlin-stdlib:1.8.0. В результате в classpath оказываются две разные версии одной библиотеки.

IDE видит конфликт версий между плагином (1.9.22) и одной из библиотек (1.8.0) — и выдаёт warning. При этом ваша явная зависимость kotlin("stdlib", "1.9.22") может быть переопределена транзитивной.

Диагностика: Как найти виновника?

Прежде чем лечить, нужно понять, откуда берётся старая версия. Используйте встроенные инструменты Gradle.

Способ 1: Gradle-задача dependencies

Запустите в терминале:

./gradlew dependencies --configuration runtimeClasspath

В выводе найдите строки, содержащие kotlin-stdlib. Вы увидите что-то вроде:

+--- org.jetbrains.kotlin:kotlin-stdlib:1.9.22
|    \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.9.22
+--- com.example:some-library:2.0.0
|    \--- org.jetbrains.kotlin:kotlin-stdlib:1.8.0 -> 1.9.22

Стрелка -> показывает, что Gradle разрешил конфликт в пользу версии 1.9.22. Но warning всё равно может остаться, если плагин анализирует исходные версии.

Способ 2: IntelliJ IDEA — Module Settings

Откройте File → Project Structure → Modules. Выберите ваш модуль и посмотрите вкладку Dependencies. Там отображаются все зависимости, включая транзитивные. Если видите kotlin-stdlib:1.8.0 (или другую версию) — это источник проблемы.

4 способа исправить warning (и повысить производительность)

Теперь перейдём к самому интересному — решениям. Каждый способ влияет на оптимизацию сборки и производительность runtime.

Способ 1: Принудительное выравнивание версий (Alignment)

Самый правильный подход — использовать Kotlin BOM (Bill of Materials). Это гарантирует, что все Kotlin-зависимости будут одной версии.

// build.gradle.kts
dependencies {
    implementation(platform("org.jetbrains.kotlin:kotlin-bom:1.9.22"))
    implementation("org.jetbrains.kotlin:kotlin-stdlib")
    // Теперь не нужно указывать версию — она берётся из BOM
}

Почему это хорошо для производительности? BOM исключает дублирование классов в classpath. Если у вас две версии kotlin-stdlib, JVM загружает обе — это лишняя память и время. BOM гарантирует, что будет только одна версия.

Способ 2: Явное исключение транзитивной зависимости

Если BOM не помогает (например, библиотека использует свою версию Kotlin, которая не переопределяется), можно явно исключить старую версию.

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

Важно: Этот метод требует осторожности. Если библиотека действительно использует API из старой версии, исключение может сломать её. Всегда тестируйте после изменений.

Способ 3: Обновление плагина Kotlin в IntelliJ IDEA

Иногда warning — это ложное срабатывание старой версии IDE. Убедитесь, что у вас установлен актуальный плагин Kotlin:

  1. Откройте Settings → Plugins.
  2. Найдите Kotlin и нажмите Update (если доступно).
  3. Перезапустите IDE.

Также проверьте версию Kotlin в Build Tools → Kotlin Compiler в настройках проекта. Она должна совпадать с той, что указана в Gradle.

Способ 4: Использование kotlin("bom") в мультимодульных проектах

Если у вас мультимодульный проект, warning может появляться из-за того, что в разных модулях указаны разные версии. Решение — вынести версию в build.gradle.kts корневого проекта:

// build.gradle.kts (root)
plugins {
    kotlin("jvm") version "1.9.22" apply false
}

subprojects {
    apply(plugin = "org.jetbrains.kotlin.jvm")
    dependencies {
        implementation(platform("org.jetbrains.kotlin:kotlin-bom:1.9.22"))
        implementation("org.jetbrains.kotlin:kotlin-stdlib")
    }
}

Это гарантирует, что все модули используют одну и ту же версию Kotlin, и warning исчезнет.

Влияние на производительность: Почему это важно?

Многие думают: «Подумаешь, warning. Сборка работает, код компилируется». На самом деле, конф

Блоги

Рекомендаций по книгам