Что нового в Kotlin 1.8.20

Как включить компилятор Kotlin K2

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

-language-version 2.0

Указать его можно в файле build.gradle(.kts):

kotlin {
   sourceSets.all {
       languageSettings {
           languageVersion = "2.0"
       }
   }
}

Предыдущий параметр компилятора -Xuse-k2 устарел.

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

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

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

• Сообщите о проблемах, возникших при работе с новым компилятором K2, в нашем трекере задач.

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

Современная и эффективная замена функции values класса Enum

Классы Enum имеют синтетическую функцию values(), которая возвращает массив объявленных констант перечисления. Однако использование массива может привести к скрытым проблемам с производительностью в Kotlin и Java. Кроме того, в большинстве API используются коллекции, для которых в итоге требуется преобразование. Чтобы устранить эти проблемы, мы добавили для классов Enum свойство entries, которое следует использовать вместо функции values(). При вызове свойство entries возвращает предварительно выделенный неизменяемый список объявленных констант перечисления.

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

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

tasks
    .withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompilationTask<*>>()
    .configureEach {
        compilerOptions
            .languageVersion
            .set(
                org.jetbrains.kotlin.gradle.dsl.KotlinVersion.KOTLIN_1_9
            )
    }

tasks
    .withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompilationTask.class)
    .configureEach {
        compilerOptions.languageVersion =
            org.jetbrains.kotlin.gradle.dsl.KotlinVersion.KOTLIN_1_9
    }

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

Объекты данных позволяют объявлять объекты с семантикой синглтона и лаконичным представлением toString(). В этом фрагменте видно, как добавление ключевого слова data к объявлению объекта улучшает читаемость результата toString():

package org.example
object MyObject
data object MyDataObject

fun main() {
    println(MyObject) // org.example.MyObject@1f32e575
    println(MyDataObject) // MyDataObject
}

Объекты data objects особенно хорошо подходят для иерархий sealed (например, иерархии sealed class или sealed interface), поскольку их удобно использовать вместе с объявлениями 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
}

data object MyDataObject {
    val x: Int = 3
}

fun main() {
    println(MyDataObject) // MyDataObject
}

import java.lang.reflect.Constructor

data object MySingleton

fun main() {
    val evilTwin = createInstanceViaReflection()

    println(MySingleton) // MySingleton
    println(evilTwin) // MySingleton

    // Even when a library forcefully creates a second instance of MySingleton, its `equals` method returns true:
    println(MySingleton == evilTwin) // true

    // Do not compare data objects via ===.
    println(MySingleton === evilTwin) // false
}

fun createInstanceViaReflection(): MySingleton {
    // Kotlin reflection does not permit the instantiation of data objects.
    // This creates a new MySingleton instance "by force" (i.e., Java platform reflection)
    // Don't do this yourself!
    return (MySingleton.javaClass.declaredConstructors[0].apply { isAccessible = true } as Constructor<MySingleton>).newInstance()
}

tasks
    .withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompilationTask<*>>()
    .configureEach {
        compilerOptions
            .languageVersion
            .set(
                org.jetbrains.kotlin.gradle.dsl.KotlinVersion.KOTLIN_1_9
            )
    }

tasks
    .withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompilationTask.class)
    .configureEach {
        compilerOptions.languageVersion =
            org.jetbrains.kotlin.gradle.dsl.KotlinVersion.KOTLIN_1_9
    }

Предварительная версия снятия ограничения на вторичные конструкторы с телами в inline-классах

В Kotlin 1.8.20 сняты ограничения на использование вторичных конструкторов с телами в inline-классах.

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

Эти проблемы были устранены в Kotlin 1.4.30, когда были сняты ограничения на блоки init. Теперь мы идём дальше и в предварительном режиме разрешаем вторичные конструкторы с телами:

@JvmInline
value class Person(private val fullName: String) {
    // Allowed since Kotlin 1.4.30:
    init { 
        check(fullName.isNotBlank()) {
            "Full name shouldn't be empty"
        }
    }

    // Preview available since Kotlin 1.8.20:
    constructor(name: String, lastName: String) : this("$name $lastName") {
        check(lastName.isNotBlank()) {
            "Last name shouldn't be empty"
        }
    }
}

tasks
    .withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompilationTask<*>>()
    .configureEach {
        compilerOptions
            .languageVersion
            .set(
                org.jetbrains.kotlin.gradle.dsl.KotlinVersion.KOTLIN_1_9
            )
    }

tasks
    .withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompilationTask.class)
    .configureEach {
        compilerOptions.languageVersion =
            org.jetbrains.kotlin.gradle.dsl.KotlinVersion.KOTLIN_1_9
    }

Как включить Kotlin/Wasm

Чтобы включить и протестировать Kotlin/Wasm, обновите файл build.gradle.kts:

plugins {
    kotlin("multiplatform") version "1.8.20"
}

kotlin {
    wasm {
        binaries.executable()
        browser {
        }
    }
    sourceSets {
        val commonMain by getting
        val commonTest by getting {
            dependencies {
                implementation(kotlin("test"))
            }
        }
        val wasmMain by getting
        val wasmTest by getting
    }
}

Чтобы запустить проект Kotlin/Wasm, необходимо обновить настройки целевой среды:

Оставьте отзыв о Kotlin/Wasm

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

• Оставьте отзыв непосредственно разработчикам в Kotlin Slack: получите приглашение и присоединитесь к каналу #webassembly.

• Сообщите о проблемах, возникших при работе с Kotlin/Wasm, в этой задаче YouTrack.

Предварительная версия ссылок на синтетические свойства Java

В Kotlin 1.8.20 появилась возможность создавать ссылки на синтетические свойства Java, например, для такого кода Java:

public class Person {
    private String name;
    private int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }
}

В Kotlin всегда можно было писать person.age, где age — синтетическое свойство. Теперь можно также создавать ссылки на Person::age и person::age. То же самое работает и для name.

val persons = listOf(Person("Jack", 11), Person("Sofie", 12), Person("Peter", 11))
    persons
        // Call a reference to Java synthetic property:
        .sortedBy(Person::age)
        // Call Java getter via the Kotlin property syntax:
        .forEach { person -> println(person.name) }

tasks
    .withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompilationTask<*>>()
    .configureEach {
        compilerOptions
            .languageVersion
            .set(
                org.jetbrains.kotlin.gradle.dsl.KotlinVersion.KOTLIN_1_9
            )
    }

tasks
    .withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompilationTask.class)
    .configureEach {
        compilerOptions.languageVersion =
            org.jetbrains.kotlin.gradle.dsl.KotlinVersion.KOTLIN_1_9
    }

Поддержка бэкенда JVM IR в задаче генерации заглушек kapt по умолчанию

В Kotlin 1.7.20 мы добавили поддержку бэкенда JVM IR в задаче генерации заглушек kapt. Начиная с этого выпуска, эта поддержка включена по умолчанию. Чтобы включить её, больше не нужно указывать kapt.use.jvm.ir=true в файле gradle.properties. Будем благодарны за ваши отзывы об этой возможности в YouTrack.

Обновление для целевых платформ Kotlin/Native

Команда Kotlin решила пересмотреть список целевых платформ, поддерживаемых Kotlin/Native, разделить их на уровни и начать устаревание некоторых из них начиная с Kotlin 1.8.20. Полный список поддерживаемых и устаревших целевых платформ см. в разделе Поддержка целевых платформ Kotlin/Native.

Следующие целевые платформы признаны устаревшими в Kotlin 1.8.20 и будут удалены в версии 1.9.20:

• iosArm32

• watchosX86

• wasm32

• mingwX86

• linuxArm32Hfp

• linuxMips32

• linuxMipsel32

Для остальных целевых платформ теперь предусмотрено три уровня поддержки, определяемых тем, насколько хорошо платформа поддерживается и тестируется в компиляторе Kotlin/Native. Целевая платформа может перейти на другой уровень. Например, в будущем мы постараемся обеспечить полную поддержку iosArm64, поскольку она важна для Kotlin Multiplatform.

Если вы автор библиотеки, эти уровни помогут вам решить, какие целевые платформы тестировать с помощью инструментов CI, а какие можно пропустить. Команда Kotlin будет использовать такой же подход при разработке официальных библиотек Kotlin, например kotlinx.coroutines.

Подробнее о причинах этих изменений читайте в нашей публикации в блоге.

Устаревание прежнего диспетчера памяти

Начиная с версии 1.8.20 прежний диспетчер памяти считается устаревшим и будет удален в версии 1.9.20. Новый диспетчер памяти включен по умолчанию начиная с версии 1.7.20 и продолжает получать обновления стабильности и улучшения производительности.

Если вы всё еще используете прежний диспетчер памяти, удалите параметр kotlin.native.binary.memoryModel=strict из файла gradle.properties и внесите необходимые изменения, следуя нашему руководству по миграции.

Новый диспетчер памяти не поддерживает целевую платформу wasm32. Эта целевая платформа также признана устаревшей в этом выпуске и будет удалена в версии 1.9.20.

Поддержка заголовков Objective-C с директивами @import

Теперь Kotlin/Native может импортировать заголовки Objective-C с директивами @import. Эта функция полезна для работы со Swift-библиотеками, в которых используются автоматически сгенерированные заголовки Objective-C, или с классами зависимостей CocoaPods, написанными на Swift.

Ранее инструмент cinterop не мог анализировать заголовки, зависящие от модулей Objective-C через директиву @import. Это было связано с отсутствием поддержки параметра -fmodules.

Начиная с Kotlin 1.8.20, вы можете использовать заголовки Objective-C с @import. Для этого передайте компилятору параметр -fmodules в файле определения в виде compilerOpts. Если вы используете интеграцию с CocoaPods, укажите параметр cinterop в блоке конфигурации функции pod() следующим образом:

kotlin {
    ios()

    cocoapods {
        summary = "CocoaPods test library"
        homepage = "https://github.com/JetBrains/kotlin"

        ios.deploymentTarget = "13.5"

        pod("PodName") {
            extraOpts = listOf("-compiler-option", "-fmodules")
        }
    }
}

Эту долгожданную функцию уже можно использовать. Будем рады вашим отзывам в YouTrack, которые помогут сделать ее стандартной в будущих выпусках.

Поддержка режима только для компоновки в плагине Cocoapods Gradle

Начиная с Kotlin 1.8.20, вы можете использовать зависимости Pod с динамическими фреймворками только для компоновки, не генерируя привязки cinterop. Это может пригодиться, если привязки cinterop уже созданы.

Рассмотрим проект из двух модулей: библиотеки и приложения. Библиотека зависит от Pod, но не создает фреймворк, а только .klib. Приложение зависит от библиотеки и создает динамический фреймворк. В этом случае нужно скомпоновать этот фреймворк с Pod, от которых зависит библиотека, но привязки cinterop не нужны, поскольку они уже созданы для библиотеки.

Чтобы включить эту функцию, используйте параметр linkOnly или свойство builder при добавлении зависимости от Pod:

cocoapods {
    summary = "CocoaPods test library"
    homepage = "https://github.com/JetBrains/kotlin"

    pod("Alamofire", linkOnly = true) {
        version = "5.7.0"
    }
}

Импорт расширений Objective-C как членов классов в UIKit

Начиная с Xcode 14.1 некоторые методы классов Objective-C были перенесены в члены категорий. Это привело к созданию другого API Kotlin, и эти методы импортировались как расширения Kotlin, а не как методы.

Возможно, вы сталкивались с проблемами при переопределении методов с помощью UIKit. Например, при создании подкласса UIView на Kotlin стало невозможно переопределять методы drawRect() или layoutSubviews().

Начиная с версии 1.8.20 члены категорий, объявленные в тех же заголовках, что и классы NSView и UIView, импортируются как члены этих классов. Это означает, что методы, унаследованные от NSView и UIView, можно легко переопределять, как и любые другие методы.

Если всё пройдет хорошо, мы планируем включить такое поведение по умолчанию для всех классов Objective-C.

Повторная реализация управления кэшем компилятора в компиляторе

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

Если возникнет проблема и потребуется вернуться к прежнему поведению, используйте свойство Gradle kotlin.native.cacheOrchestration=gradle.

Будем признательны за ваши отзывы в YouTrack.

Устаревание useLibraries() в плагине Cocoapods Gradle

В Kotlin 1.8.20 начинается цикл устаревания функции useLibraries(), используемой в интеграции с CocoaPods для статических библиотек.

Мы добавили функцию useLibraries(), позволяющую использовать зависимости от Pod, содержащих статические библиотеки. Со временем такие случаи стали очень редкими. Большинство Pod распространяются в исходном коде, а для распространения двоичных файлов обычно выбирают фреймворки Objective-C или XCFramework.

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

Подробнее о фреймворках и XCFramework см. в разделе Сборка готовых нативных двоичных файлов.

Новый подход к иерархии наборов исходного кода

В Kotlin 1.8.20 предлагается новый способ настройки иерархии наборов исходного кода в многоплатформенных проектах — иерархия целевых платформ по умолчанию. Этот подход призван заменить сокращения для целевых платформ, такие как ios, у которых есть недостатки проектирования.

Идея иерархии целевых платформ по умолчанию проста: вы явно объявляете все целевые платформы, для которых компилируется проект, а плагин Kotlin Gradle автоматически создает общие наборы исходного кода на основе указанных целевых платформ.

@OptIn(ExperimentalKotlinGradlePluginApi::class)
kotlin {
    // Enable the default target hierarchy:
    targetHierarchy.default()

    android()
    iosArm64()
    iosSimulatorArm64()
}

Предварительная версия поддержки составных сборок Gradle в Kotlin Multiplatform

Начиная с версии 1.8.20 Kotlin Multiplatform поддерживает составные сборки Gradle. Составные сборки позволяют включать сборки отдельных проектов или частей одного проекта в единую сборку.

Из-за технических сложностей поддержка составных сборок Gradle с Kotlin Multiplatform была лишь частичной. В Kotlin 1.8.20 представлена предварительная версия улучшенной поддержки, которая должна работать с большим количеством проектов. Чтобы опробовать ее, добавьте следующий параметр в gradle.properties:

kotlin.mpp.import.enableKgpDependencyResolution=true

Этот параметр включает предварительную версию нового режима импорта. Помимо поддержки составных сборок, он упрощает импорт многоплатформенных проектов: мы добавили важные исправления ошибок и улучшения, чтобы сделать импорт стабильнее.

Улучшенный вывод ошибок Gradle в Xcode

Если при сборке многоплатформенных проектов в Xcode возникали проблемы, возможно, вы сталкивались с ошибкой «Command PhaseScriptExecution failed with a nonzero exit code». Это сообщение указывает на сбой вызова Gradle, но мало помогает определить причину проблемы.

Начиная с Kotlin 1.8.20 Xcode может анализировать вывод компилятора Kotlin/Native. Кроме того, если сборка Gradle завершается с ошибкой, в Xcode появится дополнительное сообщение об ошибке из исключения, вызвавшего сбой. В большинстве случаев это поможет выявить первопричину.

Новое поведение включено по умолчанию для стандартных задач Gradle интеграции с Xcode, например embedAndSignAppleFrameworkForXcode, которая связывает фреймворк iOS из многоплатформенного проекта с приложением iOS в Xcode. Его также можно включить или отключить с помощью свойства Gradle kotlin.native.useXcodeMessageStyle.

Удаление интеграции Dukat из плагина Gradle

В Kotlin 1.8.20 мы удалили экспериментальную интеграцию Dukat из плагина Kotlin/JavaScript Gradle. Интеграция Dukat поддерживала автоматическое преобразование файлов объявлений TypeScript (.d.ts) во внешние объявления Kotlin.

Преобразовывать файлы объявлений TypeScript (.d.ts) во внешние объявления Kotlin по-прежнему можно с помощью нашего инструмента Dukat.

Имена переменных и функций Kotlin в картах исходного кода

Для упрощения отладки мы добавили возможность включать в карты исходного кода имена переменных и функций, объявленные в коде Kotlin. До версии 1.8.20 этих имен в картах исходного кода не было, поэтому в отладчике всегда отображались имена переменных и функций сгенерированного JavaScript.

Настроить добавляемые имена можно с помощью sourceMapNamesPolicy в файле Gradle build.gradle.kts или параметра компилятора -source-map-names-policy. В таблице ниже перечислены возможные значения:

Ниже приведен пример конфигурации в файле build.gradle.kts:

tasks.withType<org.jetbrains.kotlin.gradle.tasks.Kotlin2JsCompile>().configureEach {
    compilercompileOptions.sourceMapNamesPolicy.set(org.jetbrains.kotlin.gradle.dsl.JsSourceMapNamesPolicy.SOURCE_MAP_NAMES_POLICY_FQ_NAMES) // or SOURCE_MAP_NAMES_POLICY_NO, or SOURCE_MAP_NAMES_POLICY_SIMPLE_NAMES
}

Инструменты отладки, например встроенные в браузеры на основе Chromium, могут извлекать исходные имена Kotlin из карты исходного кода, чтобы сделать стек вызовов более понятным. Удачной отладки!

Явное включение генерации файлов определений TypeScript

Ранее, если проект создавал исполняемые файлы (binaries.executable()), компилятор Kotlin/JS IR собирал все объявления верхнего уровня с пометкой @JsExport и автоматически генерировал определения TypeScript в файле .d.ts.

Поскольку это нужно не каждому проекту, в Kotlin 1.8.20 поведение изменено. Чтобы генерировать определения TypeScript, необходимо явно настроить это в файле сборки Gradle. Добавьте generateTypeScriptDefinitions() в build.gradle.kts.file в разделе js. Например:

kotlin {
    js {
        binaries.executable()
        browser {
        }
        generateTypeScriptDefinitions()
    }
}

Новое выравнивание версий плагинов Gradle

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

Будем рады вашим отзывам об этой функции на YouTrack.

Инкрементальная компиляция JVM по умолчанию в Gradle

Новый подход к инкрементальной компиляции, который доступен начиная с Kotlin 1.7.0, теперь используется по умолчанию. Больше не нужно указывать kotlin.incremental.useClasspathSnapshot=true в файле gradle.properties, чтобы включить его.

Будем рады вашим отзывам. Вы можете сообщить о проблеме в YouTrack.

Точное резервное копирование результатов задач компиляции

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

Эта оптимизация имеет статус экспериментальной функции. Включить ее можно, добавив свойство Gradle kotlin.compiler.preciseCompilationResultsBackup в файл gradle.properties:

kotlin.compiler.preciseCompilationResultsBackup=true

Пример использования точного резервного копирования в JetBrains

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

На первой и второй диаграммах показано, как точное резервное копирование в проекте Kotlin влияет на сборку плагина Kotlin Gradle:

1. После небольшого изменения ABI — добавления нового публичного метода — в модуле, от которого зависит множество других модулей.

2. После небольшого изменения, не затрагивающего ABI, — добавления приватной функции — в модуле, от которого не зависят другие модули.

На третьей диаграмме показано, как точное резервное копирование в проекте Space влияет на сборку веб-интерфейса после небольшого изменения, не затрагивающего ABI, — добавления приватной функции — в модуле Kotlin/JS, от которого зависит множество других модулей.

Измерения проводились на компьютере с процессором Apple M1 Max; на других компьютерах результаты могут немного отличаться. На производительность влияют, помимо прочего, следующие факторы:

• Насколько прогреты демон Kotlin и демон Gradle.

• Скорость диска.

• Модель процессора и его загруженность.

• Какие модули затронуты изменениями и каков их размер.

• Затрагивают ли изменения ABI.

kotlin.build.report.output=file

Task ':kotlin-gradle-plugin:compileCommonKotlin' finished in 0.59 s
<...>
Time metrics:
 Total Gradle task time: 0.59 s
 Task action before worker execution: 0.24 s
  Backup output: 0.22 s // Pay attention to this number 
<...>

Task ':kotlin-gradle-plugin:compileCommonKotlin' finished in 0.46 s
<...>
Time metrics:
 Total Gradle task time: 0.46 s
 Task action before worker execution: 0.07 s
  Backup output: 0.05 s // The time has reduced
 Run compilation in Gradle worker: 0.32 s
  Clear jar cache: 0.00 s
  Precise backup output: 0.00 s // Related to precise backup
  Cleaning up the backup stash: 0.00 s // Related to precise backup
<...>

Отложенное создание задач Kotlin/JVM для всех версий Gradle

В проектах с плагином org.jetbrains.kotlin.gradle.jvm на Gradle 7.3 и выше плагин Kotlin Gradle больше не создает и не настраивает задачу compileKotlin сразу. В более ранних версиях Gradle он просто регистрирует все задачи и не настраивает их при пробном запуске. Теперь такое же поведение реализовано и для Gradle 7.3 и выше.

Нестандартное расположение destinationDirectory задач компиляции

Обновите скрипт сборки, добавив дополнительный код, если вы выполняете одно из следующих действий:

• Переопределяете расположение destinationDirectory задачи Kotlin/JVM KotlinJvmCompile/KotlinCompile.

• Используете устаревший Kotlin/JS/Non-IR вариант и переопределяете destinationDirectory задачи Kotlin2JsCompile.

Вам нужно явно добавить sourceSets.main.kotlin.classesDirectories в sourceSets.main.outputs в файл JAR:

tasks.jar(type: Jar) {
    from sourceSets.main.outputs
    from sourceSets.main.kotlin.classesDirectories
}

Возможность отказаться от передачи аргументов компилятора в службу статистики HTTP

Теперь можно указать, должен ли плагин Kotlin Gradle включать аргументы компилятора в отчеты о сборке HTTP. Иногда передавать эти аргументы в отчет не требуется. Если проект содержит много модулей, аргументы компилятора в отчете могут быть очень объемными и не слишком полезными. Теперь передачу аргументов можно отключить и тем самым сэкономить память. Укажите свойство kotlin.build.report.include_compiler_arguments=(true|false) в файле gradle.properties или local.properties.

Будем рады вашим отзывам об этой функции на YouTrack.

Поддержка интерфейса AutoCloseable

Интерфейс AutoCloseable добавлен в общую стандартную библиотеку, чтобы для закрытия ресурсов во всех библиотеках можно было использовать один общий интерфейс. В Kotlin/JVM интерфейс AutoCloseable является псевдонимом для java.lang.AutoClosable.

Кроме того, добавлена функция расширения use(), которая выполняет заданную блочную функцию для выбранного ресурса, а затем корректно закрывает его независимо от того, было ли выброшено исключение.

В общей стандартной библиотеке нет общедоступного класса, реализующего интерфейс AutoCloseable. В приведенном ниже примере мы определяем интерфейс XMLWriter и предполагаем, что существует ресурс, который его реализует. Например, таким ресурсом может быть класс, который открывает файл, записывает XML-содержимое, а затем закрывает его.

interface XMLWriter : AutoCloseable {
    fun document(encoding: String, version: String, content: XMLWriter.() -> Unit)
    fun element(name: String, content: XMLWriter.() -> Unit)
    fun attribute(name: String, value: String)
    fun text(value: String)
}

fun writeBooksTo(writer: XMLWriter) {
    writer.use { xml ->
        xml.document(encoding = "UTF-8", version = "1.0") {
            element("bookstore") {
                element("book") {
                    attribute("category", "fiction")
                    element("title") { text("Harry Potter and the Prisoner of Azkaban") }
                    element("author") { text("J. K. Rowling") }
                    element("year") { text("1999") }
                    element("price") { text("29.99") }
                }
                element("book") {
                    attribute("category", "programming")
                    element("title") { text("Kotlin in Action") }
                    element("author") { text("Dmitry Jemerov") }
                    element("author") { text("Svetlana Isakova") }
                    element("year") { text("2017") }
                    element("price") { text("25.19") }
                }
            }
        }
    }
}

Поддержка кодирования Base64

Добавлена поддержка кодирования и декодирования Base64. Предусмотрено три экземпляра класса, каждый из которых использует разные схемы кодирования и отличается поведением. Для стандартной схемы кодирования Base64 используйте экземпляр Base64.Default.

Для схемы кодирования «безопасной для URL и имен файлов» используйте экземпляр Base64.UrlSafe.

Для схемы кодирования MIME используйте экземпляр Base64.Mime. При использовании экземпляра Base64.Mime все функции кодирования вставляют разделитель строк через каждые 76 символов. При декодировании недопустимые символы пропускаются и не приводят к выбросу исключения.

val foBytes = "fo".map { it.code.toByte() }.toByteArray()
Base64.Default.encode(foBytes) // "Zm8="
// Alternatively:
// Base64.encode(foBytes)

val foobarBytes = "foobar".map { it.code.toByte() }.toByteArray()
Base64.UrlSafe.encode(foobarBytes) // "Zm9vYmFy"

Base64.Default.decode("Zm8=") // foBytes
// Alternatively:
// Base64.decode("Zm8=")

Base64.UrlSafe.decode("Zm9vYmFy") // foobarBytes

Дополнительные функции позволяют кодировать или декодировать байты в существующий буфер, а также добавлять результат кодирования к объекту типа Appendable.

В Kotlin/JVM также добавлены функции расширения encodingWith() и decodingWith(), позволяющие выполнять кодирование и декодирование Base64 с помощью потоков ввода и вывода.

Поддержка @Volatile в Kotlin/Native

Если пометить свойство var аннотацией @Volatile, то резервное поле будет помечено таким образом, что все операции чтения и записи этого поля станут атомарными, а записи всегда будут видны другим потокам.

До версии 1.8.20 в общей стандартной библиотеке была доступна аннотация kotlin.jvm.Volatile. Однако эта аннотация действует только в JVM. При использовании в Kotlin/Native она игнорируется, что может привести к ошибкам.

В версии 1.8.20 добавлена общая аннотация kotlin.concurrent.Volatile, которую можно использовать как в JVM, так и в Kotlin/Native.

tasks
    .withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompilationTask<*>>()
    .configureEach {
        compilerOptions
            .languageVersion
            .set(
                org.jetbrains.kotlin.gradle.dsl.KotlinVersion.KOTLIN_1_9
            )
    }

tasks
    .withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompilationTask.class)
    .configureEach {
        compilerOptions.languageVersion =
            org.jetbrains.kotlin.gradle.dsl.KotlinVersion.KOTLIN_1_9
    }

Исправлена ошибка переполнения стека при использовании регулярных выражений в Kotlin/Native

В предыдущих версиях Kotlin могла происходить ошибка, если входные данные регулярного выражения содержали большое количество символов, даже при очень простом шаблоне. В версии 1.8.20 эта проблема устранена. Подробнее см. KT-46211.

Прототип плагина компилятора сериализации для компилятора Kotlin K2

Начиная с версии 1.8.20 плагин компилятора сериализации работает с компилятором Kotlin K2. Попробуйте его и поделитесь с нами отзывами!

Запрет неявной настройки сериализатора через companion-объект

Сейчас можно объявить класс сериализуемым с помощью аннотации @Serializable и одновременно объявить пользовательский сериализатор, поместив аннотацию @Serializer в его companion-объект.

Например:

import kotlinx.serialization.*

@Serializable
class Foo(val a: Int) {
    @Serializer(Foo::class)
    companion object {
        // Custom implementation of KSerializer<Foo>
    }
}

В этом случае из аннотации @Serializable неясно, какой сериализатор используется. На самом деле у класса Foo есть пользовательский сериализатор.

Чтобы избежать такой путаницы, в Kotlin 1.8.20 добавлено предупреждение компилятора, которое появляется при обнаружении этого случая. Предупреждение содержит возможный путь миграции для решения проблемы.

Если в вашем коде используются такие конструкции, рекомендуем обновить их следующим образом:

import kotlinx.serialization.*

@Serializable(Foo.Companion::class)
class Foo(val a: Int) {
    // Doesn't matter if you use @Serializer(Foo::class) or not
    companion object: KSerializer<Foo> {
        // Custom implementation of KSerializer<Foo>
    }
}

При таком подходе ясно, что класс Foo использует пользовательский сериализатор, объявленный в companion-объекте. Подробнее см. задачу в YouTrack.

Проверьте версию IDE

IntelliJ IDEA 2022.2 и 2022.3 автоматически предлагают обновить плагин Kotlin до версии 1.8.20. В IntelliJ IDEA 2023.1 встроен плагин Kotlin версии 1.8.20.

Android Studio Flamingo (222) и Giraffe (223) будут поддерживать Kotlin 1.8.20 в следующих выпусках.

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

Настройка Gradle

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

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

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