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

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

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

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

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

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

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

Язык и stdlib

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

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

Вопрос: KT-27825

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

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

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

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

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

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

Вопрос: KT-31227

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

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

Краткое описание: В Kotlin 1.5 будет запрещено использование массивов, основанных на нереализованных параметрах типа, в качестве аргументов типа reified на JVM.

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

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

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

Вопрос: KT-35870

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

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

Краткое описание: В Kotlin 1.5 будут запрещены вторичные конструкторы классов перечислений, которые не делегируют первичному конструктору.

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

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

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

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

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

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

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

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

Цикл снятия с поддержки:

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

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

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

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

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

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

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

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

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

Повышение уровня устаревания преобразований типов с плавающей запятой в 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–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