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

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

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

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

• В коде 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 interop.

Улучшения обработки аннотаций для указания возможности null

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

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

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

  • Массивов

  • Varargs

  • Полей

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

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

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

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

Дополнительные сведения о безопасности null и платформах типов.

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

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

Теперь поддерживаются кэши компилятора в отладочном режиме для 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 Объекты даты и времени

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

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

Узнайте больше в блоге изменений и kotlinx-datetime записи блога о выпуске 0.2.0.