Руководство по совместимости для Kotlin 1.5

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

Хотя большинство изменений языка уже были объявлены в других каналах, таких как журналы обновлений или предупреждения компилятора, данный документ обобщает их все, предоставляя полную справку по миграции с Kotlin 1.4 на Kotlin 1.5.

Основные термины

В данном документе мы вводим несколько видов совместимости:

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

Обратите внимание, что эти определения даны только для чистого Kotlin. Совместимость кода Kotlin с точки зрения других языков (например, Java) выходит за рамки этого документа.

Язык и stdlib

Запрет использования оператора spread в вызовах с сигнатурной полиморфией

Запрет неабстрактных классов, содержащих абстрактные члены, невидимые из внутреннего пакета класса

Запрет использования массивов, основанных на нереализованных параметрах типа, в качестве реифицированных аргументов типа на JVM

Вопрос: KT-31227

Компонент: Язык Kotlin

Тип несовместимого изменения: исходный код

Краткое описание: Kotlin 1.5 запретит использование массивов, основанных на нереализованных параметрах типа, в качестве реифицированных аргументов типа на JVM

Цикл устаревания:

< 1.5: вывести предупреждение для проблемных вызовов
>= 1.5: преобразовать это предупреждение в ошибку, -XXLanguage:-ProhibitNonReifiedArraysAsReifiedTypeArguments можно использовать для временного возврата к поведению версии до 1.5

Запрет вторичных конструкторов перечислений, которые не делегируют первичному конструктору

Запрет экспонирования анонимных типов из приватных инлайновых функций

Запрет передачи нераскрывных массивов после аргументов с SAM-преобразованием

Поддержка специальной семантики для параметров блоков catch с именем подчерк

Изменение стратегии реализации SAM-преобразования с основанной на анонимных классах на invokedynamic

Проблемы производительности с JVM IR-бекендом

Проблема: KT-48233

Компонент: Kotlin/JVM

Тип несовместимого изменения: поведенческий

Краткое описание: Kotlin 1.5 по умолчанию использует IR-бекенд для компилятора Kotlin/JVM. Старый бекенд по умолчанию используется для более ранних версий языка.

При использовании новой компиляции в Kotlin 1.5 могут возникнуть проблемы с производительностью. Мы работаем над исправлением таких случаев.

Цикл устаревания:

< 1.5: по умолчанию используется старый JVM бекенд
>= 1.5: по умолчанию используется IR-бекенд. Если вам нужно использовать старый бекенд в Kotlin 1.5, добавьте следующие строки в конфигурационный файл проекта, чтобы временно вернуться к поведению до версии 1.5:

В Gradle:

tasks.withType<org.jetbrains.kotlin.gradle.dsl.KotlinJvmCompile> {
  kotlinOptions.useOldBackend = true
}

tasks.withType(org.jetbrains.kotlin.gradle.dsl.KotlinJvmCompile) {
  kotlinOptions.useOldBackend = true
}

В Maven:

<configuration>
    <args>
        <arg>-Xuse-old-backend</arg>
    </args>
</configuration>

Поддержка этого флага будет удалена в одной из будущих версий.

Новая сортировка полей в JVM IR-бекенде

Проблема: KT-46378

Компонент: Kotlin/JVM

Тип несовместимого изменения: поведенческий

Краткое описание: Начиная с версии 1.5, Kotlin использует IR-бекенд, который сортирует JVM байткод по-другому: он генерирует поля, объявленные в конструкторе, перед полями, объявленными в теле класса, в то время как в старом бекенде порядок обратный. Новая сортировка может изменить поведение программ, использующих фреймворки сериализации, которые зависят от порядка полей, таких как Java сериализация.

Цикл устаревания:

< 1.5: по умолчанию используется старый JVM бекенд. Он имеет поля, объявленные в теле класса, перед полями, объявленными в конструкторе.
>= 1.5: по умолчанию используется новый IR-бекенд. Поля, объявленные в конструкторе, генерируются перед полями, объявленными в теле. Для временного переключения на старый бекенд в Kotlin 1.5 добавьте следующие строки в конфигурационный файл проекта:

В Gradle:

tasks.withType<org.jetbrains.kotlin.gradle.dsl.KotlinJvmCompile> {
  kotlinOptions.useOldBackend = true
}

tasks.withType(org.jetbrains.kotlin.gradle.dsl.KotlinJvmCompile) {
  kotlinOptions.useOldBackend = true
}

В Maven:

<configuration>
    <args>
        <arg>-Xuse-old-backend</arg>
    </args>
</configuration>

Поддержка этого флага будет удалена в одной из будущих версий.

Генерация утверждений о непустоте для делегированных свойств с универсальным вызовом в выражении делегата

Проблема: KT-44304

Компонент: Kotlin/JVM

Тип несовместимого изменения: поведенческий

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

Цикл устаревания:

1.5: генерировать утверждения о непустоте для делегированных свойств (подробности см. в задаче), -Xuse-old-backend или -language-version 1.4 можно использовать для временного возврата к поведению до версии 1.5

Преобразование предупреждений в ошибки для вызовов с параметрами типа, помеченными аннотацией @OnlyInputTypes

Использование правильного порядка выполнения аргументов в вызовах с именованным vararg

Использование значения по умолчанию параметра в операторных функциональных вызовах

Генерация пустых обратных последовательностей в циклах for, если обычная последовательность также пуста

Устранение преобразований Char в код и Char в цифру

Несогласованное сравнение символов без учета регистра в функциях kotlin.text

Удаление API преобразования регистра с учетом локали по умолчанию

Постепенное изменение типа возвращаемого значения функций min и max для коллекций на нессылочный тип

Проблема: KT-38854

Компонент: kotlin-stdlib (JVM)

Тип несовместимого изменения: исходный код

Краткое описание: тип возвращаемого значения функций min и max для коллекций будет изменен на нессылочный в 1.6.

Цикл устаревания:

1.4: введение функций ...OrNull в качестве синонимов и устаревание затронутого API (см. подробности в проблеме)
1.5.0: повышение уровня устаревания затронутого API до ошибки
>=1.6: повторное введение затронутого API, но с нессылочным типом возвращаемого значения

Повышение уровня устаревания преобразований типов с плавающей запятой в Short и Byte

Инструменты

Не следует смешивать несколько вариантов JVM kotlin-test в одном проекте

Проблема: KT-40225

Компонент: Gradle

Тип несовместимого изменения: поведенческое

Краткое описание: несколько взаимно исключающих kotlin-test вариантов для разных фреймворков тестирования могли находиться в проекте, если один из них был добавлен зависимостью. Начиная с 1.5.0, Gradle не будет разрешать наличие взаимно исключающих kotlin-test вариантов для разных фреймворков тестирования.

Цикл устаревания:

< 1.5: разрешается иметь несколько взаимно исключающих kotlin-test вариантов для разных фреймворков тестирования
>= 1.5: поведение изменено,
Gradle генерирует исключение типа "Невозможно выбрать модуль с конфликтом по возможности...". Возможные решения:
- используйте тот же kotlin-test вариант и соответствующий фреймворк тестирования, что и зависимость.
- найдите другую версию зависимости, которая не добавляет kotlin-test вариант как транзитивную зависимость, чтобы вы могли использовать фреймворк тестирования, который хотите использовать.
- найдите другую версию зависимости, которая добавляет другой kotlin-test вариант как транзитивную зависимость, который использует тот же фреймворк тестирования, который вы хотите использовать.
- исключите фреймворк тестирования, который добавляется транзитивной зависимостью. Следующий пример для исключения JUnit 4:
```
configurations { 
    testImplementation.get().exclude("org.jetbrains.kotlin", "kotlin-test-junit")
}
```
  После исключения фреймворка тестирования протестируйте ваше приложение. Если оно перестало работать, откатайте изменения по исключению, используйте тот же фреймворк тестирования, что и библиотека, и исключите свой фреймворк тестирования.

Последнее изменение: 15 октября 2021

© 2010–2023 JetBrains s.r.o. and Kotlin Programming Language contributors
Licensed under the Apache License, Version 2.0.
https://kotlinlang.org/docs/compatibility-guide-15.html