Что нового в Kotlin 1.9.0

Совместимость плагина kapt компилятора с компилятором K2

Вы можете использовать плагин kapt в вашем проекте вместе с компилятором K2, но с некоторыми ограничениями. Несмотря на установку languageVersion в 2.0, плагин kapt компилятора по-прежнему использует старый компилятор.

Если вы выполните плагин kapt компилятора в проекте, где languageVersion установлено в 2.0, kapt автоматически переключится на 1.9 и отключит проверки совместимости определённых версий. Это поведение эквивалентно включению следующих командных аргументов:

• -Xskip-metadata-version-check

• -Xskip-prerelease-check

• -Xallow-unstable-dependencies

Эти проверки отключены исключительно для задач kapt. Все остальные задачи компиляции будут продолжать использовать новый компилятор K2.

Если у вас возникнут проблемы при использовании kapt с компилятором K2, сообщите об этом в нашем отслеживании проблем.

Попробуйте компилятор K2 в вашем проекте

Начиная с версии 1.9.0 и до выпуска Kotlin 2.0, вы можете легко протестировать компилятор K2 с помощью свойства Gradle kotlin.experimental.tryK2=true. Вы также можете выполнить следующую команду:

./gradlew assemble -Pkotlin.experimental.tryK2=true

Это свойство Gradle автоматически устанавливает версию языка на 2.0 и обновляет отчет о сборке с количеством задач Kotlin, скомпилированных с помощью компилятора K2 по сравнению с текущим компилятором:

##### 'kotlin.experimental.tryK2' results (Kotlin/Native not checked) #####
:lib:compileKotlin: 2.0 language version
:app:compileKotlin: 2.0 language version
##### 100% (2/2) tasks have been compiled with Kotlin 2.0 #####

Отчеты о сборке Gradle

Отчеты о сборке Gradle теперь показывают, был ли использован текущий или компилятор K2 для компиляции кода. В Kotlin 1.9.0 вы можете увидеть эту информацию в ваших отчётах о сборке Gradle:

Вы также можете найти используемую версию Kotlin в отчёте о сборке:

Task info:
  Kotlin language version: 1.9

Ограничения текущего компилятора K2

Включение K2 в ваш проект Gradle имеет некоторые ограничения, которые могут повлиять на проекты, использующие версии Gradle ниже 8.3 в следующих случаях:

• Компиляция исходного кода из buildSrc.

• Компиляция плагинов Gradle во включённых сборках.

• Компиляция других плагинов Gradle, если они используются в проектах с версиями Gradle ниже 8.3.

• Сборка зависимостей плагина Gradle.

Если вы столкнулись с какой-либо из вышеперечисленных проблем, вы можете предпринять следующие шаги для их решения:

• Установите версию языка для buildSrc, любых плагинов Gradle и их зависимостей:

kotlin {
    compilerOptions {
        languageVersion.set(org.jetbrains.kotlin.gradle.dsl.KotlinVersion.KOTLIN_1_9)
        apiVersion.set(org.jetbrains.kotlin.gradle.dsl.KotlinVersion.KOTLIN_1_9)
    }
}

• Обновите версию Gradle в вашем проекте до 8.3, когда она станет доступна.

Оставьте свой отзыв о новом компиляторе K2

Мы будем признательны за любой ваш отзыв!

• Поделитесь своим отзывом напрямую разработчикам K2 в Slack Kotlin – получите приглашение и присоединитесь к каналу #k2-early-adopters.

• Сообщите о любых проблемах, с которыми вы столкнулись при использовании нового компилятора K2, в нашем отслеживании проблем.

• Включите опцию Отправка статистических данных о использовании, чтобы разрешить JetBrains собирать анонимные данные об использовании K2.

Стабильная замена функции enum class values

В 1.8.20 свойство entries для классов перечислений было введено как экспериментальная функция. Свойство entries является современной и эффективной заменой для синтетической функции values(). В 1.9.0 свойство entries является стабильным.

enum class Color(val colorName: String, val rgb: String) {
    RED("Red", "#FF0000"),
    ORANGE("Orange", "#FF7F00"),
    YELLOW("Yellow", "#FFFF00")
}

fun findByRgb(rgb: String): Color? = Color.entries.find { it.rgb == rgb }

Дополнительную информацию о свойстве entries для классов перечислений см. в Новом в Kotlin 1.8.20.

Стабильные объекты данных для симметрии с классами данных

Объявления объектов данных, которые были введены в Kotlin 1.8.20, теперь являются стабильными. Это включает функции, добавленные для симметрии с классами данных: toString(), equals(), и hashCode().

Эта функция особенно полезна с sealed иерархиями (например, sealed class или sealed interface), потому что объявления data object удобно использовать вместе с объявлениями data class. В этом примере объявление EndOfFile в качестве data object вместо простого object означает, что у него автоматически есть функция toString() без необходимости ручного переопределения. Это поддерживает симметрию с сопутствующими определениями класса данных.

sealed interface ReadResult
data class Number(val number: Int) : ReadResult
data class Text(val text: String) : ReadResult
data object EndOfFile : ReadResult

fun main() {
    println(Number(7)) // Number(number=7)
    println(EndOfFile) // EndOfFile
}

Дополнительную информацию см. в Новом в Kotlin 1.8.20.

Поддержка вторичных конструкторов с телами в инлайновых классах значений

Начиная с Kotlin 1.9.0, использование вторичных конструкторов с телами в инлайновых классах значений доступно по умолчанию:

@JvmInline
value class Person(private val fullName: String) {
    // Allowed since Kotlin 1.4.30:
    init {
        check(fullName.isNotBlank()) {
            "Full name shouldn't be empty"
        }
    }
    // Allowed by default since Kotlin 1.9.0:
    constructor(name: String, lastName: String) : this("$name $lastName") {
        check(lastName.isNotBlank()) {
            "Last name shouldn't be empty"
        }
    }
}

Ранее Kotlin допускал только публичные первичные конструкторы в инлайновых классах. В результате было невозможно инкапсулировать основополагающие значения или создать инлайновый класс, который бы представлял некоторые ограниченные значения.

По мере развития Kotlin эти проблемы были решены. Kotlin 1.4.30 снял ограничения на блоки init, а затем Kotlin 1.8.20 представил предварительный просмотр вторичных конструкторов с телами. Они теперь доступны по умолчанию. Подробнее об эволюции инлайновых классов Kotlin см. в этом KEEP.

Устаревание аннотации JvmDefault и устаревших режимов -Xjvm-default

Начиная с Kotlin 1.5, использование аннотации JvmDefault устарело в пользу новых режимов -Xjvm-default: all и all-compatibility С введением JvmDefaultWithoutCompatibility в Kotlin 1.4 и JvmDefaultWithCompatibility в Kotlin 1.6, эти режимы предлагают комплексный контроль над генерацией классов DefaultImpls, гарантируя бесшовную совместимость со старым кодом Kotlin.

Следовательно, в Kotlin 1.9.0 аннотация JvmDefault больше не имеет значения и была помечена как устаревшая, что приведет к ошибке. В конечном счете, она будет удалена из Kotlin.

Изменения в поддержке платформы Android

Мы продолжаем работу по стабилизации Kotlin Многоплатформенность. Важным шагом является обеспечение первоклассной поддержки платформы Android. Мы рады объявить, что в будущем команда Android из Google предоставит свой собственный плагин Gradle для поддержки Android в Kotlin Многоплатформенность.

Чтобы открыть путь для этого нового решения от Google, мы переименовали блок android в текущем Kotlin DSL в версии 1.9.0. Пожалуйста, замените все вхождения блока android на androidTarget в ваших скриптах сборки. Это временное изменение, необходимое для освобождения имени android для предстоящего DSL от Google.

Плагин Google станет предпочтительным способом работы с Android в многоплатформенных проектах. Когда он будет готов, мы предоставим необходимые инструкции по миграции, чтобы вы могли использовать краткое имя android как и прежде.

Новая структура наборов исходных файлов Android по умолчанию

Начиная с Kotlin 1.9.0, новая структура наборов исходных файлов Android установлена по умолчанию. Она заменила предыдущую схему именования каталогов, которая была неоднозначной. Новая структура имеет ряд преимуществ:

• Упрощенная семантика типов — Новая структура наборов исходных файлов Android обеспечивает ясные и согласованные соглашения об именовании, которые помогают различать различные типы наборов исходных файлов.

• Улучшенная структура каталогов исходных файлов — С новой структурой расположение SourceDirectories становится более согласованным, что упрощает организацию кода и поиск исходных файлов.

• Ясная схема именования конфигураций Gradle — Схема стала более согласованной и предсказуемой как в KotlinSourceSets, так и в AndroidSourceSets.

Новая структура требует версии плагина Android Gradle 7.0 или выше и поддерживается в Android Studio 2022.3 и более поздних версиях. Обратитесь к нашему руководству по миграции, чтобы внести необходимые изменения в ваш файл build.gradle(.kts).

Предварительный просмотр кэша конфигурации Gradle

Kotlin 1.9.0 включает поддержку кэша конфигурации Gradle в многоплатформенных библиотеках. Если вы являетесь автором библиотеки, вы уже можете получить выгоду от улучшенной производительности сборки.

Кэш конфигурации Gradle ускоряет процесс сборки, повторно используя результаты фазы конфигурации для последующих сборок. Функция стала стабильной начиная с Gradle 8.1. Чтобы включить её, следуйте инструкциям в документации Gradle.

Оптимизации размера

Kotlin 1.9.0 вносит существенные улучшения в размер проектов WebAssembly (Wasm). Сравнивая два проекта «Hello World», занимаемый объем кода Wasm в Kotlin 1.9.0 теперь более чем в 10 раз меньше, чем в Kotlin 1.8.20.

Эти оптимизации размера приводят к более эффективному использованию ресурсов и улучшенной производительности при использовании Kotlin-кода для платформ Wasm.

Обновления в взаимодействии с JavaScript

Это обновление Kotlin вносит изменения во взаимодействие между Kotlin и JavaScript для Kotlin/Wasm. Так как Kotlin/Wasm является экспериментальной функцией, на его взаимодействие накладываются определённые ограничения.

Устаревание плагина Kotlin/JS Gradle

Начиная с Kotlin 1.9.0, плагин kotlin-js Gradle устарел. Рекомендуется использовать плагин kotlin-multiplatform Gradle с целевым параметром js().

Функциональность плагина Kotlin/JS Gradle в основном дублировала плагин kotlin-multiplatform и использовала одну и ту же реализацию внутри. Это дублирование создавало путаницу и увеличивало нагрузку на команду Kotlin по сопровождению.

Обратитесь к нашему руководству по совместимости Kotlin Multiplatform за инструкциями по миграции. Если вы обнаружите проблемы, которые не охвачены в руководстве, сообщите об этом в нашем трекере ошибок.

Устаревание внешних перечислений

В Kotlin 1.9.0 использование внешних перечислений будет устаревшим из-за проблем со статическими членами перечислений, такими как entries, которые не могут существовать вне Kotlin. Рекомендуется использовать вместо этого внешние запечатанные классы с подклассами типа object:

// Before
external enum class ExternalEnum { A, B }

// After
external sealed class ExternalEnum {
    object A: ExternalEnum
    object B: ExternalEnum
}

Переход на внешний запечатанный класс с подклассами типа object позволит добиться сходной функциональности внешних перечислений, избежав проблем, связанных с методами по умолчанию.

Начиная с Kotlin 1.9.0, использование внешних перечислений будет помечено как устаревшее. Рекомендуется обновить код для использования предлагаемой реализации внешнего запечатанного класса для совместимости и последующего обслуживания.

Экспериментальная поддержка ES6 классов и модулей

В этом релизе представлена экспериментальная поддержка ES6 модулей и генерации ES6 классов:

• Модули предлагают способ упростить вашу кодовую базу и улучшить ее поддержку.

• Классы позволяют включить принципы объектно-ориентированного программирования (ООП), что приводит к более чистому и интуитивному коду.

Для активации этих функций необходимо соответствующим образом обновить файл build.gradle.kts.

// build.gradle.kts
kotlin { 
    js(IR) { 
        useEsModules() // Enables ES6 modules
        browser()
        }
    }

// Enables ES6 classes generation
tasks.withType<KotlinJsCompile>().configureEach {
    kotlinOptions {
        useEsClasses = true
    }
}

Узнайте больше о ECMAScript 2015 (ES6) в официальной документации.

Изменение целевого каталога для JS-распределения (производство)

До Kotlin 1.9.0, целевой каталог распределения был build/distributions. Однако это общий каталог для архивов Gradle. Для решения этой проблемы, мы изменили целевой каталог распределения по умолчанию в Kotlin 1.9.0 на: build/dist/<targetName>/<binaryName>.

Например, productionExecutable находился в build/distributions. В Kotlin 1.9.0 он находится в build/dist/js/productionExecutable.

Извлечение объявлений org.w3c из stdlib-js

Начиная с Kotlin 1.9.0, stdlib-js больше не включает org.w3c объявления. Вместо этого эти объявления были перенесены в отдельную зависимость Gradle. Когда вы добавляете плагин Kotlin Multiplatform Gradle в свой файл build.gradle.kts, эти объявления будут автоматически включены в ваш проект, аналогично стандартной библиотеке.

Для этого не требуется никаких ручных действий или миграции. Необходимые корректировки будут выполнены автоматически.

Удаленный параметр classpath

В Kotlin 1.7.0 мы объявили начало цикла устаревания для свойства задачи KotlinCompile: classpath. Уровень устаревания был повышен до ERROR в Kotlin 1.8.0. В этом релизе мы окончательно удалили свойство classpath. Все задачи компиляции теперь должны использовать вход libraries для списка библиотек, необходимых для компиляции.

Новые параметры компилятора

Плагин Kotlin Gradle теперь предоставляет новые свойства для включения и прогрессивного режима компилятора.

• Для включения новых API вы теперь можете использовать свойство optIn и передавать список строк, например: optIn.set(listOf(a, b, c)).

• Для включения прогрессивного режима используйте progressiveMode.set(true).

Параметры компилятора на уровне проекта для Kotlin/JVM

Начиная с Kotlin 1.9.0, доступен новый блок compilerOptions внутри блока конфигурации kotlin.

kotlin {
    compilerOptions {
        jvmTarget.set(JVM.Target_11)
    }
}

Это значительно упрощает настройку параметров компилятора. Однако важно обратить внимание на некоторые детали:

• Эта конфигурация работает только на уровне проекта.

• Для плагина Android этот блок настраивает тот же объект, что и:

android {
    kotlinOptions {}
}

• Блоки конфигурации android.kotlinOptions и kotlin.compilerOptions перекрывают друг друга. Последний (нижний) блок в файле сборки всегда вступает в силу.

• Если moduleName сконфигурирован на уровне проекта, его значение может быть изменено при передаче в компилятор. Это не относится к компиляции main, но для других типов, например, тестовых источников, плагин Kotlin Gradle добавит суффикс _test.

• Конфигурация внутри tasks.withType<KotlinJvmCompile>().configureEach {} (или tasks.named<KotlinJvmCompile>("compileKotlin") { }) перекрывает как kotlin.compilerOptions, так и android.kotlinOptions.

Параметр компилятора для имени модуля Kotlin/Native

Параметр компилятора Kotlin/Native module-name теперь легко доступен в плагине Kotlin Gradle.

Этот параметр задаёт имя модуля компиляции и также может использоваться для добавления префикса имени для объявлений, экспортируемых в Objective-C.

Теперь вы можете задать имя модуля непосредственно в блоке compilerOptions файлов сборки Gradle:

tasks.named<org.jetbrains.kotlin.gradle.tasks.KotlinNativeCompile>("compileKotlinLinuxX64") {
    compilerOptions {
        moduleName.set("my-module-name")
    }
}

tasks.named("compileKotlinLinuxX64", org.jetbrains.kotlin.gradle.tasks.KotlinNativeCompile.class) {
    compilerOptions {
        moduleName = "my-module-name"
    }
}

Отдельные плагины компилятора для официальных библиотек Kotlin

Kotlin 1.9.0 вводит отдельные плагины компилятора для своих официальных библиотек. Ранее плагины компилятора были встроены в соответствующие плагины Gradle. Это могло привести к проблемам совместимости, если плагин компилятора был скомпилирован с Kotlin-версией выше, чем версия Kotlin runtime в Gradle сборке.

Теперь плагины компилятора добавляются как отдельные зависимости, поэтому у вас больше не будет проблем совместимости со старыми версиями Gradle. Другое важное преимущество нового подхода заключается в том, что новые плагины компилятора могут использоваться с другими системами сборки, такими как Bazel.

Вот список новых плагинов компилятора, которые мы теперь публикуем в Maven Central:

• kotlin-atomicfu-compiler-plugin

• kotlin-allopen-compiler-plugin

• kotlin-lombok-compiler-plugin

• kotlin-noarg-compiler-plugin

• kotlin-sam-with-receiver-compiler-plugin

• kotlinx-serialization-compiler-plugin

Каждый плагин имеет свой аналог -embeddable, например, kotlin-allopen-compiler-plugin-embeddable предназначен для работы с артефактом kotlin-compiler-embeddable, — параметром по умолчанию для артефактов скриптов.

Gradle добавляет эти плагины в качестве аргументов компилятора. Вам не нужно вносить какие-либо изменения в существующие проекты.

Увеличена минимально поддерживаемая версия

Начиная с Kotlin 1.9.0, минимально поддерживаемая версия Android Gradle Plugin составляет 4.2.2.

См. совместимость плагина Kotlin Gradle с доступными версиями Gradle в нашей документации.

kapt не вызывает создание задач в Gradle

До версии 1.9.0 плагин компилятора kapt вызывал создание задач в принудительном режиме, запрашивая настроенный экземпляр задачи компиляции Kotlin. Это поведение исправлено в Kotlin 1.9.0. Если вы используете стандартную конфигурацию для файла build.gradle.kts, то ваша настройка не затронута этим изменением.

Дополнительную информацию можно найти в нашей записи в YouTrack.

Программная настройка режима проверки соответствия JVM-цели

До Kotlin 1.9.0 существовал только один способ настройки обнаружения несовместимости между Kotlin и Java в отношении JVM-цели. Вам нужно было установить kotlin.jvm.target.validation.mode=ERROR в gradle.properties для всего проекта.

Теперь вы также можете настроить его на уровне задачи в файле build.gradle.kts:

tasks.named<org.jetbrains.kotlin.gradle.tasks.KotlinJvmCompile>("compileKotlin") {
    jvmTargetValidationMode.set(org.jetbrains.kotlin.gradle.dsl.jvm.JvmTargetValidationMode.WARNING)
}

Проверка версии IDE

IntelliJ IDEA 2022.3.3 и 2023.1.1 автоматически предлагают обновить плагин Kotlin до версии 1.9.0. IntelliJ IDEA 2023.2 будет включать плагин Kotlin 1.9.0.

Android Studio Giraffe (223) и Hedgehog (231) будут поддерживать Kotlin 1.9.0 в своих будущих выпусках.

Новый компилятор командной строки доступен для скачивания на странице выпусков GitHub.

Настройка настроек Gradle

Для загрузки артефактов и зависимостей Kotlin обновите свой файл settings.gradle(.kts) для использования репозитория Maven Central:

pluginManagement {
    repositories {
        mavenCentral()
        gradlePluginPortal()
    }
}

Если репозиторий не указан, Gradle использует устаревший репозиторий JCenter, что может привести к проблемам с артефактами Kotlin.