Что нового в Kotlin 1.5.0

Поддержка JVM-записей

Java быстро развивается, и для обеспечения совместимости Kotlin с ним мы внедрили поддержку одной из её последних функций – классы-записи.

Поддержка Kotlin для JVM-записей включает двустороннюю совместимость:

• В Kotlin-коде вы можете использовать классы-записи Java так же, как и обычные классы с свойствами.

• Чтобы использовать класс Kotlin в качестве записи в Java-коде, сделайте его data классом и отметьте его аннотацией @JvmRecord.

@JvmRecord
data class User(val name: String, val age: Int)

Узнайте больше о работе с JVM-записями в Kotlin.

Закрытые интерфейсы

В Kotlin интерфейсы теперь могут иметь модификатор sealed, который работает с интерфейсами так же, как и с классами: все реализации закрытого интерфейса известны на этапе компиляции.

sealed interface Polygon

Вы можете полагаться на этот факт, например, для написания исчерпывающих when выражений.

fun draw(polygon: Polygon) = when (polygon) {
   is Rectangle -> // ...
   is Triangle -> // …
   // else is not needed - all possible implementations are covered
}

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

class FilledRectangle: Polygon, Fillable

Узнайте больше о закрытых интерфейсах.

Иерархии закрытых классов по всему пакету

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

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

Подклассы закрытого класса должны иметь надлежаще квалифицированное имя — они не могут быть локальными или анонимными объектами.

Узнайте больше об иерархиях закрытых классов.

Встроенные классы

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

Встроенные классы могут быть объявлены с модификатором value перед именем класса:

value class Password(val s: String)

JVM-бекенд также требует специальной аннотации @JvmInline.

@JvmInline
value class Password(val s: String)

Модификатор inline теперь устарел с предупреждением.

Узнайте больше о встроенных классах.

Стабильный JVM IR бэкенд

Базовая часть IR-основанного бэкенда для компилятора Kotlin/JVM теперь стабильна и включена по умолчанию.

Начиная с Kotlin 1.4.0, предварительные версии IR-основанного бэкенда были доступны для предварительного просмотра, и теперь он является по умолчанию для версии языка 1.5. Старый бэкенд по-прежнему используется по умолчанию для более ранних версий языка.

Дополнительные сведения о преимуществах IR-бэкенда и его дальнейшей разработке можно найти в этой публикации в блоге.

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

• В 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 цель: 1.8

Версия цели по умолчанию для компиляций Kotlin/JVM теперь 1.8. Цель 1.6 устарела.

Если вам нужна сборка для JVM 1.6, вы всё ещё можете переключиться на эту цель. Узнайте как:

• в Gradle

• в Maven

• в компиляторе командной строки

SAM адаптеры через invokedynamic

Kotlin 1.5.0 теперь использует динамические вызовы (invokedynamic) для компиляции преобразований SAM (Single Abstract Method):

• Над любым выражением, если тип SAM — интерфейс Java

• Над лямбдой, если тип SAM — функциональный интерфейс Kotlin

Новая реализация использует LambdaMetafactory.metafactory(), и вспомогательные оберточные классы больше не генерируются во время компиляции. Это уменьшает размер JAR приложения, что улучшает производительность запуска JVM.

Чтобы вернуться к старой схеме реализации, основанной на генерации анонимных классов, добавьте опцию компилятора -Xsam-conversions=class.

Узнайте, как добавить опции компилятора в Gradle, Maven и компилятор командной строки.

Лямбды через invokedynamic

Kotlin 1.5.0 вводит экспериментальную поддержку компиляции обычных лямбд Kotlin (которые не преобразуются в экземпляр функционального интерфейса) в динамические вызовы (invokedynamic). Реализация создаёт более лёгкие бинарники, используя LambdaMetafactory.metafactory(), которая эффективно генерирует необходимые классы во время выполнения. В настоящее время у неё есть три ограничения по сравнению с обычной компиляцией лямбд:

• Лямбда, скомпилированная в invokedynamic, не сериализуема.

• Вызов toString() для такой лямбды даёт менее читабельное строковое представление.

• Экспериментальный reflect API не поддерживает лямбды, созданные с помощью LambdaMetafactory.

Чтобы попробовать эту функцию, добавьте опцию компилятора -Xlambdas=indy. Мы будем благодарны, если вы поделитесь своими отзывами об этом с помощью этого YouTrack-заявки.

Узнайте, как добавить опции компилятора в Gradle, Maven и компилятор командной строки.

Устаревание @JvmDefault и старых режимов Xjvm-default

До Kotlin 1.4.0 существовала аннотация @JvmDefault вместе с режимами -Xjvm-default=enable и -Xjvm-default=compatibility. Они использовались для создания JVM-метода по умолчанию для любого конкретного неабстрактного члена в Kotlin-интерфейсе.

В Kotlin 1.4.0 мы представили новые Xjvm-default режимы, которые включают генерацию методов по умолчанию для всего проекта.

В Kotlin 1.5.0 мы устареваем аннотацию @JvmDefault и старые режимы Xjvm-default: -Xjvm-default=enable и -Xjvm-default=compatibility.

Узнайте больше о методах по умолчанию в Java-совместимости.

Улучшения обработки аннотаций нулевости

Kotlin поддерживает обработку информации о нулевости типов из Java с помощью аннотаций нулевости. Kotlin 1.5.0 вносит ряд улучшений в эту функциональность:

• Он читает аннотации нулевости на аргументах типа в скомпилированных Java-библиотеках, используемых как зависимости.

• Он поддерживает аннотации нулевости с целевой версией TYPE_USE для:

  • Массивов

  • Varargs

  • Полей

  • Параметров типа и их границ

  • Аргументов типа базовых классов и интерфейсов

• Если аннотация нулевости имеет несколько подходящих целей для типа, и одна из них — TYPE_USE, то TYPE_USE имеет приоритет. Например, сигнатура метода @Nullable String[] f() становится fun f(): Array<String?>! если @Nullable поддерживает как TYPE_USE так и METHOD в качестве целей.

Для этих новых поддерживаемых случаев использование неверного типа нулевости при вызове Java из Kotlin генерирует предупреждения. Используйте опцию компилятора -Xtype-enhancement-improvements-strict-mode для включения строгого режима для этих случаев (с сообщением об ошибке).

Узнайте больше о безопасности при работе с null и платформах.

Улучшения производительности

В версии 1.5.0 Kotlin/Native получило набор улучшений производительности, которые ускоряют как компиляцию, так и выполнение.

Кэши компилятора (Compiler caches) теперь поддерживаются в режиме отладки для linuxX64 (только на хостах Linux) и iosArm64 целевых платформ. При включенных кэшах компиляции, большинство отладочных компиляций завершаются значительно быстрее, за исключением первой. Измерения показали увеличение скорости на наших тестовых проектах примерно на 200%.

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

• Для linuxX64: kotlin.native.cacheKind.linuxX64=static

• Для iosArm64: kotlin.native.cacheKind.iosArm64=static

Если вы столкнётесь с проблемами после включения кэшей компилятора, пожалуйста, сообщите о них в наш отслеживатель ошибок YouTrack.

Другие улучшения ускоряют выполнение кода Kotlin/Native:

• Тривиальные аксессоры свойств инлайнены.

• trimIndent() для строковых литералов вычисляется во время компиляции.

Отключение проверки утечек памяти

Встроенная проверка утечек памяти Kotlin/Native по умолчанию отключена.

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

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

Platform.isMemoryLeakCheckerActive = true

Обратите внимание, что включение проверки утечек памяти для выполнения приложения не рекомендуется.

Обновление до webpack 5

Плагин Kotlin/JS Gradle теперь использует webpack 5 для браузерных целей вместо webpack 4. Это значительное обновление webpack, которое вносит несовместимые изменения. Если вы используете пользовательскую конфигурацию webpack, обязательно ознакомьтесь с заметками о выпуске webpack 5.

Дополнительные сведения о сборке проектов Kotlin/JS с помощью webpack.

Фреймворки и библиотеки для компилятора IR

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

Многие известные фреймворки и библиотеки уже доступны для бэкенда IR: KVision, fritz2, doodle и другие. Если вы используете их в своём проекте, вы уже можете скомпилировать его с бэкендом IR и увидеть преимущества, которые он предоставляет.

Если вы пишете собственную библиотеку, скомпилируйте её в режиме "both", чтобы ваши клиенты также могли использовать её с новым компилятором.

Упрощенное использование зависимостей для тестирования в многоплатформенных проектах

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

• kotlin-test-junit для наборов исходных кодов JVM, см. автоматический выбор фреймворка для тестирования для наборов исходных кодов Kotlin/JVM

• kotlin-test-js для наборов исходных кодов Kotlin/JS

• kotlin-test-common и kotlin-test-annotations-common для общих наборов исходных кодов

• Дополнительных артефактов для наборов исходных кодов Kotlin/Native не требуется

Кроме того, вы можете использовать зависимость kotlin-test в любом общем или платформенно-специфичном наборе исходных кодов.

Существующая настройка kotlin-test с явными зависимостями будет продолжать работать как в Gradle, так и в Maven.

Подробнее о установке зависимостей от библиотек тестов.

Автоматический выбор фреймворка для тестирования для наборов исходных кодов Kotlin/JVM

Плагин Gradle теперь автоматически выбирает и добавляет зависимость от фреймворка для тестирования. Всё, что вам нужно сделать, это добавить зависимость kotlin-test в общий набор исходных кодов.

По умолчанию Gradle использует JUnit 4. Поэтому зависимость kotlin("test") разрешается до варианта для JUnit 4, а именно kotlin-test-junit:

kotlin {
    sourceSets {
        val commonTest by getting {
            dependencies {
                implementation(kotlin("test")) // This brings the dependency
                                               // on JUnit 4 transitively
            }
        }
    }
}

kotlin {
    sourceSets {
        commonTest {
            dependencies {
                implementation kotlin("test") // This brings the dependency 
                                              // on JUnit 4 transitively
            }
        }
    }
}

Вы можете выбрать JUnit 5 или TestNG, вызвав useJUnitPlatform() или useTestNG() в задаче тестирования:

tasks {
    test {
        // enable TestNG support
        useTestNG()
        // or
        // enable JUnit Platform (a.k.a. JUnit 5) support
        useJUnitPlatform()
    }
}

Вы можете отключить автоматический выбор фреймворка для тестирования, добавив строку kotlin.test.infer.jvm.variant=false в gradle.properties проекта.

Подробнее о установке зависимостей от библиотек тестов.

Обновления функций проверки

Этот релиз содержит новые функции проверки и улучшения существующих.

Библиотека kotlin-test теперь имеет следующие функции:

• Проверка типа значения

  Вы можете использовать новые функции assertIs<T> и assertIsNot<T> для проверки типа значения:

  @Test
  fun testFunction() {
      val s: Any = "test"
      assertIs<String>(s)  // throws AssertionError mentioning the actual type of s if the assertion fails
      // can now print s.length because of contract in assertIs
      println("${s.length}")
  }
  

  Из-за стирания типов эта функция проверки только проверяет, является ли value значением типа List в примере ниже, и не проверяет, является ли это списком конкретного типа элемента String: assertIs<List<String>>(value).

• Сравнение содержимого контейнера для массивов, последовательностей и произвольных итерируемых объектов

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

  @Test
  fun test() {
      val expectedArray = arrayOf(1, 2, 3)
      val actualArray = Array(3) { it + 1 }
      assertContentEquals(expectedArray, actualArray)
  }
  

• Новые перегрузки для assertEquals() и assertNotEquals() для чисел Double и Float

  Существуют новые перегрузки для функции assertEquals(), которые позволяют сравнивать два числа Double или Float с абсолютной точностью. Значение точности задается как третий параметр функции:

   @Test
  fun test() {
      val x = sin(PI)
  
      // precision parameter
      val tolerance = 0.000001
  
      assertEquals(0.0, x, tolerance)
  }
  

• Новые функции для проверки содержимого коллекций и элементов

  Теперь вы можете проверить, содержит ли коллекция или элемент что-то с помощью функции assertContains(). Вы можете использовать ее с коллекциями Kotlin и элементами, которые имеют оператор contains(), такие как IntRange, String, и другие:

  @Test
  fun test() {
      val sampleList = listOf<String>("sample", "sample2")
      val sampleString = "sample"
      assertContains(sampleList, sampleString)  // element in collection
      assertContains(sampleString, "amp")       // substring in string
  }
  

• assertTrue(), assertFalse(), expect() функции теперь являются inline

  Теперь вы можете использовать их как inline-функции, поэтому вы можете вызывать отложенные функции внутри лямбда-выражения:

  @Test
  fun test() = runBlocking<Unit> {
      val deferred = async { "Kotlin is nice" }
      assertTrue("Kotlin substring should be present") {
          deferred.await() .contains("Kotlin")
      }
  }
  

Coroutines 1.5.0-RC

kotlinx.coroutines 1.5.0-RC доступен с:

• Новый API каналов

• Стабильные реактивные интеграции

• И многое другое

Начиная с Kotlin 1.5.0, экспериментальные coroutines отключены, а флаг -Xcoroutines=experimental больше не поддерживается.

Узнайте больше в блоге изменений и в kotlinx.coroutines блоге о релизе 1.5.0.

Serialization 1.2.1

kotlinx.serialization 1.2.1 доступен с:

• Улучшения производительности JSON сериализации

• Поддержка нескольких имён в JSON сериализации

• Экспериментальная генерация схемы .proto из классов @Serializable

• И многое другое

Узнайте больше в блоге изменений и в kotlinx.serialization блоге о релизе 1.2.1.

dateTime 0.2.0

kotlinx-datetime 0.2.0 доступен с:

• @Serializable Объекты Datetime

• Нормализованный API DateTimePeriod и DatePeriod

• И многое другое

Узнайте больше в блоге изменений и в kotlinx-datetime блоге о релизе 0.2.0.