Что нового в 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 для включения строгих режимов для этих случаев (с сообщением об ошибке).

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

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

В версии 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.