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

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

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

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

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

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

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

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

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

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

Запрет использования массивов, основанных на не-рефинированных параметрах типа, в качестве рефинированных аргументов типа на 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-to-code и Char-to-digit

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

Последнее изменение: 10 января 2023

© 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