Что нового в Kotlin 2.2.0

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

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

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

Контекстные параметры заменяют старую экспериментальную возможность, называвшуюся контекстными получателями. Чтобы перейти с контекстных получателей на контекстные параметры, воспользуйтесь специальной поддержкой в IntelliJ IDEA, описанной в публикации в блоге.

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

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

// UserService defines the dependency required in the context 
interface UserService {
    fun log(message: String)
    fun findUserById(id: Int): String
}

// Declares a function with a context parameter
context(users: UserService)
fun outputMessage(message: String) {
    // Uses log from the context
    users.log("Log: $message")
}

// Declares a property with a context parameter
context(users: UserService)
val firstUser: String
    // Uses findUserById from the context    
    get() = users.findUserById(1)

// Uses "_" as context parameter name
context(_: UserService)
fun logWelcome() {
    // Finds the appropriate log function from UserService
    outputMessage("Welcome!")
}

-Xcontext-parameters

// build.gradle.kts
kotlin {
    compilerOptions {
        freeCompilerArgs.add("-Xcontext-parameters")
    }
}

Предварительная версия контекстно-зависимого разрешения

В Kotlin 2.2.0 представлена предварительная реализация контекстно-зависимого разрешения.

Обзор этой возможности можно посмотреть в видео:

Ранее требовалось указывать полные имена элементов перечисления или членов запечатанного класса, даже если тип можно было вывести из контекста. Например:

enum class Problem {
    CONNECTION, AUTHENTICATION, DATABASE, UNKNOWN
}

fun message(problem: Problem): String = when (problem) {
    Problem.CONNECTION -> "connection"
    Problem.AUTHENTICATION -> "authentication"
    Problem.DATABASE -> "database"
    Problem.UNKNOWN -> "unknown"
}

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

enum class Problem {
    CONNECTION, AUTHENTICATION, DATABASE, UNKNOWN
}

// Resolves enum entries based on the known type of problem
fun message(problem: Problem): String = when (problem) {
    CONNECTION -> "connection"
    AUTHENTICATION -> "authentication"
    DATABASE -> "database"
    UNKNOWN -> "unknown"
}

Компилятор использует эти сведения о типе из контекста, чтобы разрешить правильный член. В частности, учитываются следующие сведения:

• Тема выражения when

• Явно указанный тип возвращаемого значения

• Объявленный тип переменной

• Проверки типа (is) и приведения типов (as)

• Известный тип иерархии запечатанных классов

• Объявленный тип параметра

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

-Xcontext-sensitive-resolution

Или добавьте его в блок compilerOptions {} файла сборки Gradle:

// build.gradle.kts
kotlin {
    compilerOptions {
        freeCompilerArgs.add("-Xcontext-sensitive-resolution")
    }
}

Мы планируем стабилизировать и улучшить эту возможность в будущих выпусках Kotlin и будем благодарны за ваши отзывы в нашем трекере задач YouTrack.

Предварительная версия возможностей для use-site-целей аннотаций

В Kotlin 2.2.0 представлены две возможности, упрощающие работу с use-site-целями аннотаций.

data class User(
    val username: String,

    @param:Email      // Constructor parameter
    @field:Email      // Backing field
    @get:Email        // Getter method
    @property:Email   // Kotlin property reference
    val email: String,
) {
    @field:Email
    @get:Email
    @property:Email
    val secondaryEmail: String? = null
}

data class User(
    val username: String,

    // Applies @Email to param, property, field,
    // get, and setparam (if var)
    @all:Email val email: String,
) {
    // Applies @Email to property, field, and get
    // (no param since it's not in the constructor)
    @all:Email val secondaryEmail: String? = null
}

-Xannotation-target-all

// build.gradle.kts
kotlin {
    compilerOptions {
        freeCompilerArgs.add("-Xannotation-target-all")
    }
}

// build.gradle.kts
kotlin {
    compilerOptions {
        freeCompilerArgs.add("-Xannotation-default-target=param-property")
    }
}

-Xannotation-default-target=param-property

Поддержка вложенных псевдонимов типов

В Kotlin 2.2.0 добавлена поддержка объявления псевдонимов типов внутри других объявлений.

Обзор этой возможности можно посмотреть в видео:

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

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

class Dijkstra {
    typealias VisitedNodes = Set<Node>

    private fun step(visited: VisitedNodes, ...) = ...
}

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

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

-Xnested-type-aliases

// build.gradle.kts
kotlin {
    compilerOptions {
        freeCompilerArgs.add("-Xnested-type-aliases")
    }
}

Стабильные возможности: условия-стражи, нелокальные break и continue, а также интерполяция с несколькими знаками доллара

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

• Условия-стражи в when с темой

• Нелокальные break и continue

• Интерполяция с несколькими знаками доллара: улучшенная обработка $ в строковых литералах

Полный список предложений и возможностей, связанных с проектированием языка Kotlin.

Как использовать

Новый параметр компилятора имеет следующий синтаксис:

-Xwarning-level=DIAGNOSTIC_NAME:(error|warning|disabled)

• error: превращает указанное предупреждение в ошибку.

• warning: выдаёт предупреждение; этот режим включён по умолчанию.

• disabled: полностью отключает указанное предупреждение для всего модуля.

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

Примеры использования

Новое решение позволяет точнее настраивать выдачу предупреждений в проекте, сочетая общие правила с отдельными. Выберите нужный сценарий:

Оставьте отзыв

Новый параметр компилятора пока имеет статус экспериментального. Сообщайте о проблемах в нашем трекере задач YouTrack.

Изменения в генерации методов по умолчанию для функций интерфейсов

Начиная с Kotlin 2.2.0 функции, объявленные в интерфейсах, компилируются в методы JVM по умолчанию, если не заданы другие настройки. Это изменение влияет на компиляцию функций интерфейсов Kotlin с реализациями в байткод.

Это поведение контролируется новым стабильным параметром компилятора -jvm-default, который заменяет устаревший параметр -Xjvm-default.

Управлять поведением параметра -jvm-default можно с помощью следующих значений:

• enable (по умолчанию): генерирует реализации по умолчанию в интерфейсах и включает функции-мосты в подклассы и классы DefaultImpls. Используйте этот режим для сохранения бинарной совместимости с более ранними версиями Kotlin.

• no-compatibility: генерирует только реализации по умолчанию в интерфейсах. В этом режиме пропускаются мосты совместимости и классы DefaultImpls, что делает его подходящим для нового кода.

• disable: отключает реализации по умолчанию в интерфейсах. Генерируются только функции-мосты и классы DefaultImpls, что соответствует поведению до Kotlin 2.2.0.

Чтобы настроить параметр компилятора -jvm-default, задайте свойство jvmDefault в Gradle Kotlin DSL:

// build.gradle.kts
kotlin {
    compilerOptions {
        jvmDefault = JvmDefaultMode.NO_COMPATIBILITY
    }
}

Поддержка чтения и записи аннотаций в метаданных Kotlin

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

Теперь в Kotlin 2.2.0 библиотека Kotlin Metadata JVM поддерживает чтение аннотаций, хранящихся в метаданных Kotlin.

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

-Xannotations-in-metadata

Также его можно добавить в блок compilerOptions {} файла сборки Gradle:

// build.gradle.kts
kotlin {
    compilerOptions {
        freeCompilerArgs.add("-Xannotations-in-metadata")
    }
}

Если этот параметр включен, компилятор Kotlin записывает аннотации в метаданные вместе с байткодом JVM, делая их доступными для библиотеки kotlin-metadata-jvm.

Библиотека предоставляет следующие API для доступа к аннотациям:

• KmClass.annotations

• KmFunction.annotations

• KmProperty.annotations

• KmConstructor.annotations

• KmPropertyAccessorAttributes.annotations

• KmValueParameter.annotations

• KmFunction.extensionReceiverAnnotations

• KmProperty.extensionReceiverAnnotations

• KmProperty.backingFieldAnnotations

• KmProperty.delegateFieldAnnotations

• KmEnumEntry.annotations

Эти API являются экспериментальными. Чтобы включить их, используйте аннотацию @OptIn(ExperimentalAnnotationsInMetadata::class).

Пример чтения аннотаций из метаданных Kotlin:

@file:OptIn(ExperimentalAnnotationsInMetadata::class)

import kotlin.metadata.ExperimentalAnnotationsInMetadata
import kotlin.metadata.jvm.KotlinClassMetadata

annotation class Label(val value: String)

@Label("Message class")
class Message

fun main() {
    val metadata = Message::class.java.getAnnotation(Metadata::class.java)
    val kmClass = (KotlinClassMetadata.readStrict(metadata) as KotlinClassMetadata.Class).kmClass
    println(kmClass.annotations)
    // [@Label(value = StringValue("Message class"))]
}

Улучшенная совместимость с Java для inline-классов-значений

В Kotlin 2.2.0 появилась новая экспериментальная аннотация: @JvmExposeBoxed. Эта аннотация упрощает использование inline-классов-значений из Java.

Обзор этой функции представлен в видео:

По умолчанию Kotlin компилирует inline-классы-значения в неупакованном представлении. Оно обеспечивает более высокую производительность, но часто затрудняет или даже делает невозможным использование классов из Java. Например:

@JvmInline value class PositiveInt(val number: Int) {
    init { require(number >= 0) }
}

В этом случае класс не упакован, поэтому в Java нет доступного конструктора для вызова. Также из Java нельзя запустить блок init, чтобы убедиться, что значение number положительное.

Если аннотировать класс с помощью @JvmExposeBoxed, Kotlin сгенерирует открытый конструктор, который можно напрямую вызвать из Java, и блок init также будет выполнен.

Аннотацию @JvmExposeBoxed можно применять на уровне класса, конструктора или функции, чтобы точно контролировать, что будет доступно из Java.

Например, в следующем коде функция расширения .timesTwoBoxed() недоступна из Java:

@JvmInline
value class MyInt(val value: Int)

fun MyInt.timesTwoBoxed(): MyInt = MyInt(this.value * 2)

Чтобы можно было создать экземпляр класса MyInt и вызвать функцию .timesTwoBoxed() из кода Java, добавьте аннотацию @JvmExposeBoxed и к классу, и к функции:

@JvmExposeBoxed
@JvmInline
value class MyInt(val value: Int)

@JvmExposeBoxed
fun MyInt.timesTwoBoxed(): MyInt = MyInt(this.value * 2)

С такими аннотациями компилятор Kotlin генерирует доступный из Java конструктор для класса MyInt. Он также генерирует перегрузку функции расширения, использующую упакованное представление класса-значения. В результате следующий код Java выполняется успешно:

MyInt input = new MyInt(5);
MyInt output = ExampleKt.timesTwoBoxed(input);

Если вы не хотите аннотировать каждую часть inline-классов-значений, которую нужно сделать доступной, можно применить аннотацию ко всему модулю. Чтобы включить такое поведение для модуля, скомпилируйте его с параметром -Xjvm-expose-boxed. Компиляция с этим параметром равносильна добавлению аннотации @JvmExposeBoxed к каждому объявлению модуля.

Эта новая аннотация не меняет способ внутренней компиляции и использования классов-значений в Kotlin, и весь существующий скомпилированный код остается действительным. Она лишь добавляет новые возможности для улучшения совместимости с Java. Производительность кода Kotlin, использующего классы-значения, не меняется.

Аннотация @JvmExposeBoxed полезна авторам библиотек, которым нужно предоставлять упакованные варианты функций-членов и получать упакованные типы возвращаемых значений. Она избавляет от необходимости выбирать между inline-классом-значением (эффективным, но доступным только в Kotlin) и data-классом (совместимым с Java, но всегда упакованным).

Подробное объяснение работы аннотации @JvmExposedBoxed и решаемых ею проблем см. в предложении KEEP.

Улучшенная поддержка аннотирования записей JVM

Kotlin поддерживает записи JVM начиная с Kotlin 1.5.0. Теперь в Kotlin 2.2.0 улучшена обработка аннотаций компонентов записей, особенно в отношении цели Java RECORD_COMPONENT.

Во-первых, если вы хотите использовать RECORD_COMPONENT в качестве цели аннотации, необходимо вручную добавить аннотации для Kotlin (@Target) и Java. Это связано с тем, что аннотация @Target в Kotlin не поддерживает RECORD_COMPONENT. Например:

@Target(AnnotationTarget.CLASS, AnnotationTarget.PROPERTY)
@java.lang.annotation.Target(ElementType.CLASS, ElementType.RECORD_COMPONENT)
annotation class exampleClass

Поддерживать оба списка вручную может быть непросто, поэтому в Kotlin 2.2.0 добавлено предупреждение компилятора, если цели Kotlin и Java не совпадают. Например, если в списке целей Java пропустить ElementType.CLASS, компилятор сообщит:

Incompatible annotation targets: Java target 'CLASS' missing, corresponding to Kotlin targets 'CLASS'.

Во-вторых, поведение Kotlin отличается от Java при распространении аннотаций в записях. В Java аннотации компонента записи автоматически применяются к резервному полю, геттеру и параметру конструктора. По умолчанию Kotlin этого не делает, но теперь такое поведение можно воспроизвести с помощью цели применения @all:.

Например:

@JvmRecord
data class Person(val name: String, @all:Positive val age: Int)

При использовании @JvmRecord с @all: Kotlin теперь:

• Распространяет аннотацию на свойство, резервное поле, параметр конструктора и геттер.

• Также применяет аннотацию к компоненту записи, если аннотация поддерживает цель Java RECORD_COMPONENT.

Выделение памяти для каждого объекта

Аллокатор памяти Kotlin/Native теперь может резервировать память для каждого объекта отдельно. В некоторых случаях это может помочь соблюсти строгие ограничения памяти или снизить потребление памяти при запуске приложения.

Эта новая функция предназначена для замены параметра компилятора -Xallocator=std, который включал системный аллокатор памяти вместо стандартного. Теперь можно отключить буферизацию (постраничное выделение памяти), не переключая аллокаторы памяти.

В настоящее время функция экспериментальная. Чтобы включить ее, задайте следующий параметр в файле gradle.properties:

kotlin.native.binary.pagedAllocator=false

Сообщайте о любых проблемах в наш трекер задач YouTrack.

Поддержка строк в кодировке Latin-1 во время выполнения

Теперь Kotlin поддерживает строки в кодировке Latin-1, как и JVM. Это должно помочь уменьшить размер двоичных файлов приложения и оптимизировать потребление памяти.

По умолчанию строки в Kotlin хранятся в кодировке UTF-16, где каждый символ занимает два байта. В некоторых случаях из-за этого строки занимают в двоичном файле вдвое больше места, чем в исходном коде, а чтение данных из простого файла ASCII может потребовать вдвое больше памяти, чем занимает сам файл на диске.

Кодировка Latin-1 (ISO 8859-1), в свою очередь, представляет каждый из первых 256 символов Unicode всего одним байтом. Если поддержка Latin-1 включена, строки хранятся в этой кодировке, пока все символы входят в ее диапазон. В противном случае используется кодировка UTF-16 по умолчанию.

kotlin.native.binary.latin1Strings=true

Улучшенное отслеживание потребления памяти на платформах Apple

Начиная с Kotlin 2.2.0 память, выделенная кодом Kotlin, помечается тегами. Это может помочь при отладке проблем с памятью на платформах Apple.

При изучении высокого потребления памяти приложением теперь можно определить, сколько памяти зарезервировано кодом Kotlin. Память, используемая Kotlin, помечена идентификатором, и ее можно отслеживать с помощью таких инструментов, как VM Tracker в Xcode Instruments.

Эта функция включена по умолчанию, но доступна только в стандартном аллокаторе памяти Kotlin/Native, если выполнены все следующие условия:

• Маркировка включена. Память должна быть помечена допустимым идентификатором. Apple рекомендует числа от 240 до 255; значение по умолчанию — 246.

  Если задать свойство Gradle kotlin.native.binary.mmapTag=0, маркировка будет отключена.

• Выделение с помощью mmap. Аллокатор должен использовать системный вызов mmap для отображения файлов в память.

  Если задать свойство Gradle kotlin.native.binary.disableMmap=true, стандартный аллокатор будет использовать malloc вместо mmap.

• Постраничное выделение включено. Постраничное выделение памяти (буферизация) должно быть включено.

  Если задать свойство Gradle kotlin.native.binary.pagedAllocator=false, память вместо этого будет резервироваться для каждого объекта отдельно.

Дополнительные сведения о потреблении памяти в Kotlin см. в документации.

Обновление LLVM с версии 16 до 19

В Kotlin 2.2.0 мы обновили LLVM с версии 16 до версии 19. Новая версия содержит улучшения производительности, исправления ошибок и обновления безопасности.

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

Поддержка Windows 7 объявлена устаревшей

Начиная с Kotlin 2.2.0 минимальная поддерживаемая версия Windows повышена с Windows 7 до Windows 10. Поскольку Microsoft прекратила поддержку Windows 7 в январе 2025 года, мы также решили объявить эту устаревшую целевую платформу устаревшей.

Дополнительные сведения см. в разделе Поддерживаемые целевые платформы и хосты Kotlin/Native.

Инфраструктура сборки Wasm отделена от инфраструктуры JavaScript

Раньше целевая платформа wasmJs использовала ту же инфраструктуру, что и целевая платформа js. В результате обе платформы находились в одном каталоге (build/js) и использовали одни и те же задачи и конфигурации NPM.

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

Кроме того, файлы проектов, связанные с Wasm, и зависимости NPM теперь хранятся в отдельном каталоге build/wasm.

Для Wasm добавлены новые задачи, связанные с NPM, а существующие задачи JavaScript теперь предназначены только для JavaScript:

Аналогичным образом добавлены новые объявления, специфичные для Wasm:

Теперь можно работать с целевой платформой Wasm независимо от целевой платформы JavaScript, что упрощает процесс настройки.

Это изменение включено по умолчанию и не требует дополнительной настройки.

Настройка Binaryen для каждого проекта

Ранее инструмент Binaryen, используемый в Kotlin/Wasm для оптимизации production-сборок, настраивался один раз в корневом проекте.

Теперь инструмент Binaryen можно настраивать для каждого проекта или модуля. Это соответствует рекомендациям по использованию Gradle и обеспечивает лучшую поддержку таких возможностей, как изоляция проектов, повышая производительность и надежность сборки сложных проектов.

Кроме того, при необходимости теперь можно задавать разные версии Binaryen для разных модулей.

Эта функция включена по умолчанию. Однако, если вы используете собственную конфигурацию Binaryen, теперь ее нужно применять для каждого проекта, а не только в корневом проекте.

Исправление для copy() в интерфейсах @JsPlainObject

В Kotlin/JS есть экспериментальный плагин js-plain-objects, добавляющий функцию copy() для интерфейсов с аннотацией @JsPlainObject. Функцию copy() можно использовать для обработки объектов.

Однако первоначальная реализация copy() была несовместима с наследованием, что вызывало проблемы, если интерфейс @JsPlainObject наследовал другие интерфейсы.

Чтобы избежать ограничений для простых объектов, функция copy() перемещена с самого объекта в его объект-компаньон:

@JsPlainObject
external interface User {
    val name: String
    val age: Int
}

fun main() {
    val user = User(name = "SomeUser", age = 21)
    // This syntax is not valid anymore
    val copy = user.copy(age = 35)      
    // This is the correct syntax
    val copy = User.copy(user, age = 35)
}

Это изменение устраняет конфликты в иерархии наследования и неоднозначность. Начиная с Kotlin 2.2.0 оно включено по умолчанию.

Поддержка псевдонимов типов в файлах с аннотацией @JsModule

Ранее файлы с аннотацией @JsModule, предназначенные для импорта объявлений из модулей JavaScript, могли содержать только внешние объявления. Это означало, что в таких файлах нельзя было объявить typealias.

Начиная с Kotlin 2.2.0 в файлах, помеченных @JsModule, можно объявлять псевдонимы типов:

@file:JsModule("somepackage")
package somepackage
typealias SomeClass = Any

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

Поддержка псевдонимов типов в файлах с @JsModule включена по умолчанию.

Поддержка @JsExport в мультиплатформенных объявлениях expect

При работе с механизмом expect/actual в проектах Kotlin Multiplatform было невозможно использовать аннотацию @JsExport для объявлений expect в общем коде.

Начиная с этого выпуска аннотацию @JsExport можно применять непосредственно к объявлениям expect:

// commonMain

// Produced error, but now works correctly 
@JsExport
expect class WindowManager {
    fun close()
}

@JsExport
fun acceptWindowManager(manager: WindowManager) {
    ...
}

// jsMain

@JsExport
actual class WindowManager {
    fun close() {
        window.close()
    }
}

Также необходимо добавить аннотацию @JsExport к соответствующей реализации actual в исходном наборе JavaScript, используя только типы, доступные для экспорта.

Это исправление позволяет корректно экспортировать в JavaScript общий код, определенный в commonMain. Теперь мультиплатформенный код можно предоставлять потребителям JavaScript без ручных обходных решений.

Это изменение включено по умолчанию.

Возможность использовать @JsExport с типом Promise<Unit>

Ранее при попытке экспортировать функцию, возвращающую тип Promise<Unit>, с аннотацией @JsExport компилятор Kotlin выдавал ошибку.

Типы возвращаемых значений вроде Promise<Int> работали корректно, но при использовании Promise<Unit> появлялось предупреждение «тип нельзя экспортировать», хотя в TypeScript этот тип корректно сопоставлялся с Promise<void>.

Это ограничение снято. Теперь следующий код компилируется без ошибок:

// Worked correctly before
@JsExport
fun fooInt(): Promise<Int> = GlobalScope.promise {
    delay(100)
    return@promise 42
}

// Produced error, but now works correctly
@JsExport
fun fooUnit(): Promise<Unit> = GlobalScope.promise {
    delay(100)
}

Это изменение снимает ненужное ограничение модели взаимодействия Kotlin/JS. Исправление включено по умолчанию.

Проверка бинарной совместимости в плагине Kotlin Gradle

Чтобы упростить проверку бинарной совместимости между версиями библиотеки, мы экспериментируем с переносом функциональности средства проверки бинарной совместимости в плагин Kotlin Gradle (KGP). Вы можете попробовать его в тестовых проектах, но пока мы не рекомендуем использовать его в production.

В ходе этого экспериментального этапа поддержка исходного средства проверки бинарной совместимости продолжается.

Библиотеки Kotlin могут использовать один из двух бинарных форматов: файлы классов JVM или klib. Поскольку эти форматы несовместимы, KGP работает с каждым из них отдельно.

Чтобы включить набор функций проверки бинарной совместимости, добавьте следующий код в блок kotlin{} файла build.gradle.kts:

// build.gradle.kts
kotlin {
    @OptIn(org.jetbrains.kotlin.gradle.dsl.abi.ExperimentalAbiValidation::class)
    abiValidation {
        // Use the set() function to ensure compatibility with older Gradle versions
        enabled.set(true)
    }
}

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

После включения функции запустите задачу Gradle checkLegacyAbi, чтобы проверить наличие проблем с бинарной совместимостью. Эту задачу можно запустить в IntelliJ IDEA или из командной строки в каталоге проекта:

./gradlew checkLegacyAbi

Эта задача создает дамп двоичного интерфейса приложения (ABI) из текущего кода в виде текстового файла UTF-8. Затем задача сравнивает новый дамп с дампом предыдущего выпуска. Если задача обнаруживает различия, она сообщает о них как об ошибках. Проверив ошибки и решив, что изменения допустимы, можно обновить эталонный дамп ABI, запустив задачу Gradle updateLegacyAbi.

// build.gradle.kts
kotlin {
    @OptIn(org.jetbrains.kotlin.gradle.dsl.abi.ExperimentalAbiValidation::class)
    abiValidation {
        filters.excluded.byNames.add("com.company.**")
    }
}

// build.gradle.kts
kotlin {
    @OptIn(org.jetbrains.kotlin.gradle.dsl.abi.ExperimentalAbiValidation::class)
    abiValidation {
        klib {
            keepUnsupportedTargets = false
        }
    }
}

Поддержка расширенного вывода в консоли плагина Kotlin Gradle

В Kotlin 2.2.0 добавлена поддержка цветного и другого расширенного вывода в консоли во время сборки Gradle, что упрощает чтение и понимание диагностических сообщений.

Расширенный вывод доступен в поддерживаемых эмуляторах терминала для Linux и macOS; мы работаем над добавлением поддержки Windows.

Эта функция включена по умолчанию. Чтобы переопределить это поведение, добавьте следующее свойство Gradle в файл gradle.properties:

org.gradle.console=plain

Подробнее об этом свойстве и его параметрах см. в документации Gradle, в разделе Настройка формата журнала.

Интеграция Problems API в диагностику KGP

Ранее плагин Kotlin Gradle (KGP) мог сообщать о диагностических событиях, таких как предупреждения и ошибки, только в виде обычного текста в консоли или журналах.

Начиная с версии 2.2.0, в KGP появился дополнительный механизм формирования отчетов: теперь он использует Problems API Gradle — стандартизированный способ предоставления подробной структурированной информации о проблемах во время сборки.

Теперь диагностику KGP проще читать, и она более единообразно отображается в различных интерфейсах, таких как CLI Gradle и IntelliJ IDEA.

Эта интеграция включена по умолчанию начиная с Gradle 8.6. Поскольку API продолжает развиваться, используйте последнюю версию Gradle, чтобы получать самые свежие улучшения.

Совместимость KGP с --warning-mode

Диагностика плагина Kotlin Gradle (KGP) сообщала о проблемах с фиксированными уровнями серьезности, поэтому параметр командной строки Gradle --warning-mode не влиял на отображение ошибок KGP.

Теперь диагностика KGP совместима с параметром --warning-mode, что обеспечивает большую гибкость. Например, можно преобразовать все предупреждения в ошибки или полностью отключить предупреждения.

После этого изменения диагностика KGP корректирует вывод в соответствии с выбранным режимом предупреждений:

• При установке --warning-mode=fail диагностика с уровнем Severity.Warning теперь повышается до уровня Severity.Error.

• При установке --warning-mode=none диагностика с уровнем Severity.Warning не записывается в журнал.

Это поведение включено по умолчанию начиная с версии 2.2.0.

Чтобы игнорировать параметр --warning-mode, задайте следующее свойство Gradle в файле gradle.properties:

kotlin.internal.diagnostics.ignoreWarningMode=true

Улучшенная стратегия выполнения компилятора «в процессе»

KGP поддерживает три стратегии выполнения компилятора Kotlin. Стратегия «в процессе», при которой компилятор запускается внутри процесса демона Gradle, ранее не поддерживала инкрементальную компиляцию.

Теперь благодаря BTA стратегия «в процессе» поддерживает инкрементальную компиляцию. Чтобы использовать ее, добавьте следующее свойство в файл gradle.properties:

kotlin.compiler.execution.strategy=in-process

Гибкая настройка различных версий компилятора Kotlin

Иногда может потребоваться использовать в коде более новую версию компилятора Kotlin, оставив KGP на старой версии, — например, чтобы попробовать новые языковые возможности и при этом продолжить работу над устаревшими элементами скриптов сборки. Или же может понадобиться обновить версию KGP, оставив старую версию компилятора Kotlin.

BTA позволяет это сделать. Вот как настроить его в файле build.gradle.kts:

// build.gradle.kts
import org.jetbrains.kotlin.buildtools.api.ExperimentalBuildToolsApi
import org.jetbrains.kotlin.gradle.ExperimentalKotlinGradlePluginApi

plugins { 
    kotlin("jvm") version "2.2.0"
}

group = "org.jetbrains.example"
version = "1.0-SNAPSHOT"

repositories { 
    mavenCentral()
}

kotlin { 
    jvmToolchain(8)
    @OptIn(ExperimentalBuildToolsApi::class, ExperimentalKotlinGradlePluginApi::class) 
    compilerVersion.set("2.1.21") // Different version than 2.2.0
}

BTA поддерживает настройку версий KGP и компилятора Kotlin в пределах трех предыдущих основных версий и одной последующей основной версии. Поэтому в KGP 2.2.0 поддерживаются версии компилятора Kotlin 2.1.x, 2.0.x и 1.9.25. KGP 2.2.0 также совместим с будущими версиями компилятора Kotlin 2.2.x и 2.3.x.

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

Попробуйте BTA с этими плагинами и отправьте отзыв в соответствующие задачи YouTrack для KGP и плагина Maven.

Стабильное кодирование и декодирование Base64

В Kotlin 1.8.20 была добавлена экспериментальная поддержка кодирования и декодирования Base64. В Kotlin 2.2.0 API Base64 получил статус стабильного и включает четыре схемы кодирования. В этом выпуске добавлена новая схема Base64.Pem:

• Base64.Default использует стандартную схему кодирования Base64.

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

• Base64.Mime использует схему кодирования MIME: при кодировании через каждые 76 символов вставляется разделитель строк, а при декодировании пропускаются недопустимые символы.

• Base64.Pem кодирует данные так же, как Base64.Mime, но ограничивает длину строки 64 символами.

С помощью API Base64 можно кодировать двоичные данные в строку Base64 и декодировать ее обратно в байты.

Пример:

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

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

import kotlin.io.encoding.*
import java.io.ByteArrayOutputStream

fun main() {
    val output = ByteArrayOutputStream()
    val base64Output = output.encodingWith(Base64.Default)

    base64Output.use { stream ->
        stream.write("Hello World!!".encodeToByteArray()) 
    }

    println(output.toString())
    // SGVsbG8gV29ybGQhIQ==
}

Стабильный разбор и форматирование шестнадцатеричных чисел с помощью API HexFormat

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

Например:

fun main() {
    //sampleStart
    println(93.toHexString())
    //sampleEnd
}

Подробнее см. в разделе Новый класс HexFormat для форматирования и разбора шестнадцатеричных чисел.

Поддержка ссылок на @Composable-функции

Начиная с выпуска Kotlin 2.2.0 компилятор Compose поддерживает объявление и использование ссылок на composable-функции:

val content: @Composable (String) -> Unit = ::Text

@Composable fun App() {
    content("My App")
}

Ссылки на composable-функции во время выполнения немного отличаются от объектов composable-лямбд. В частности, composable-лямбды обеспечивают более точный контроль над пропуском, наследуясь от класса ComposableLambda. От ссылок на функции ожидается реализация интерфейса KCallable, поэтому применить к ним такую же оптимизацию нельзя.

Флаг функции PausableComposition включен по умолчанию

Флаг функции PausableComposition включен по умолчанию начиная с Kotlin 2.2.0. Этот флаг изменяет вывод компилятора Compose для перезапускаемых функций, позволяя среде выполнения принудительно пропускать их и тем самым фактически приостанавливать композицию. Благодаря этому тяжелые композиции можно разделять между кадрами; эта возможность будет использоваться при предварительной загрузке в одном из будущих выпусков.

Чтобы отключить этот флаг функции, добавьте следующий код в конфигурацию Gradle:

// build.gradle.kts
composeCompiler {
    featureFlag = setOf(ComposeFeatureFlag.PausableComposition.disabled())
}

Флаг функции OptimizeNonSkippingGroups включен по умолчанию

Флаг функции OptimizeNonSkippingGroups включен по умолчанию начиная с Kotlin 2.2.0. Эта оптимизация повышает производительность во время выполнения, удаляя вызовы групп, сгенерированные для composable-функций, которые нельзя пропустить. Она не должна приводить к каким-либо наблюдаемым изменениям поведения во время выполнения.

Если вы столкнулись с проблемами, отключите этот флаг функции, чтобы проверить, вызвано ли изменение именно ими. Сообщайте о проблемах в систему отслеживания проблем Jetpack Compose.

Чтобы отключить флаг OptimizeNonSkippingGroups, добавьте следующий код в конфигурацию Gradle:

composeCompiler {
    featureFlag = setOf(ComposeFeatureFlag.OptimizeNonSkippingGroups.disabled())
}

Устаревшие флаги функций

Флаги функций StrongSkipping и IntrinsicRemember теперь считаются устаревшими и будут удалены в одном из будущих выпусков. Если вы столкнулись с проблемами, из-за которых приходится отключать эти флаги функций, сообщите о них в систему отслеживания проблем Jetpack Compose.

Новые и обновлённые руководства

• Промежуточный тур по Kotlin – Углубите свои знания Kotlin. Узнайте, когда использовать функции-расширения, интерфейсы, классы и многое другое.

• Создание приложения на Kotlin с использованием Spring AI – Узнайте, как создать приложение на Kotlin, которое отвечает на вопросы с помощью OpenAI и векторной базы данных.

• Создание проекта Spring Boot на Kotlin – Узнайте, как создать проект Spring Boot с помощью Gradle и мастера Новый проект в IntelliJ IDEA.

• Серия руководств по сопоставлению Kotlin и C – Узнайте, как сопоставляются различные типы и конструкции в Kotlin и C.

• Создание приложения с помощью взаимодействия с C и libcurl – Создайте простой HTTP-клиент, который может работать в нативной среде с использованием библиотеки C libcurl.

• Создание библиотеки Kotlin Multiplatform – Узнайте, как создать и опубликовать мультиплатформенную библиотеку с помощью IntelliJ IDEA.

• Создание полнофункционального приложения с помощью Ktor и Kotlin Multiplatform – В этом руководстве вместо Fleet теперь используется IntelliJ IDEA, а также Material 3 и последние версии Ktor и Kotlin.

• Управление локальной средой ресурсов в приложении Compose Multiplatform – Узнайте, как управлять средой ресурсов приложения, например темой и языком внутри приложения.

Новые и обновлённые страницы

• Обзор Kotlin для ИИ – Узнайте о возможностях Kotlin для создания приложений на основе ИИ.

• Руководство по миграции Dokka – Узнайте, как перейти на версию 2 плагина Dokka Gradle.

• Библиотека Kotlin Metadata JVM – Изучите рекомендации по чтению, изменению и созданию метаданных классов Kotlin, скомпилированных для JVM.

• Интеграция с CocoaPods – Узнайте, как настроить среду, добавить зависимости Pod или использовать проект Kotlin в качестве зависимости CocoaPod, следуя руководствам и примерам проектов.

• Новые страницы Compose Multiplatform, посвящённые стабильному выпуску для iOS:

  • Навигация и, в частности, глубокие ссылки.

  • Реализация макетов в Compose.

  • Локализация строк и другие страницы по интернационализации, например о поддержке языков с письмом справа налево.

• Compose Hot Reload – Узнайте, как использовать Compose Hot Reload для настольных целевых платформ и добавлять его в существующий проект.

• Миграции Exposed – Узнайте об инструментах Exposed для управления изменениями схемы базы данных.