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

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

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

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

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

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

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

Язык и стандартная библиотека

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

Запрет неабстрактных классов, содержащих абстрактные члены, невидимые из внутреннего пакета (internal/package-private)

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

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

Компонент: Язык ядра

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

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

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

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

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

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

Запрет передачи нераскротых массивов после аргументов с 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>

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

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

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

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

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

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

Прямые преобразования Char в код и Char в цифры выведены

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

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

Постепенное изменение типа возврата функций min и max коллекций на не-nullable

Повышение уровня устаревания преобразований чисел с плавающей запятой в 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")
}
```
  После исключения фреймворка тестирования протестируйте своё приложение. Если оно перестало работать, верните исключение изменений, используйте тот же фреймворк тестирования, что и библиотека, и исключите свой фреймворк тестирования.

Последнее изменение: 07 апреля 2022

© 2010–2022 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