Что нового в Kotlin 1.5.30

Создание экземпляров аннотационных классов

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

annotation class InfoMarker(val info: String)

fun processInfo(marker: InfoMarker) = ...

fun main(args: Array<String>) {
    if (args.size != 0)
        processInfo(getAnnotationReflective(args))
    else
        processInfo(InfoMarker("default"))
}

Используйте опцию компилятора -language-version 1.6 для включения этой функции. Обратите внимание, что все текущие ограничения классов аннотаций, такие как ограничения на определение параметров, не являющихся val, или членов, отличных от вторичных конструкторов, остаются неизменными.

Дополнительную информацию о создании экземпляров аннотационных классов см. в этом KEEP

Улучшенная конфигурация поддержки аннотаций нулевости

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

В Kotlin 1.5.30 можно указать, должен ли компилятор сообщать о несовпадениях нулевости на основе информации из конкретных типов аннотаций нулевости. Просто используйте опцию компилятора -Xnullability-annotations=@<package-name>:<report-level>. В аргументе укажите полное имя пакета аннотаций нулевости и один из этих уровней отчёта:

• ignore, чтобы игнорировать несовпадения нулевости

• warn, чтобы сообщать предупреждения

• strict, чтобы сообщать об ошибках.

См. полный список поддерживаемых аннотаций нулевости вместе с их полными именами пакетов.

Вот пример, показывающий, как включить отчёт об ошибках для вновь поддерживаемых аннотаций нулевости RxJava 3: -Xnullability-annotations=@io.reactivex.rxjava3.annotations:strict. Обратите внимание, что все такие несовпадения нулевости по умолчанию являются предупреждениями.

Поддержка Apple silicon

Kotlin 1.5.30 вводит поддержку Apple silicon.

Ранее компилятор и инструменты Kotlin/Native требовали среды перевода Rosetta для работы на хостах с Apple silicon. В Kotlin 1.5.30 среда перевода больше не требуется — компилятор и инструменты могут работать на оборудовании Apple silicon без дополнительных действий.

Мы также представили новые цели, которые позволяют коду Kotlin запускаться непосредственно на Apple silicon:

• macosArm64

• iosSimulatorArm64

• watchosSimulatorArm64

• tvosSimulatorArm64

Они доступны как на хостах на базе Intel, так и на хостах с Apple silicon. Все существующие цели также доступны на хостах с Apple silicon.

Обратите внимание, что в 1.5.30 мы предоставляем только базовую поддержку целей Apple silicon в плагине Gradle kotlin-multiplatform. В частности, новые цели симулятора не включены в ios, tvos и watchos сокращения целей. Узнайте, как использовать цели Apple silicon с сокращениями целей. Мы будем продолжать работу над улучшением пользовательского опыта с новыми целями.

Улучшенный Kotlin DSL для плагина CocoaPods Gradle

cocoapods {
    frameworkName = "MyFramework" // This property is deprecated 
    // and will be removed in future versions
    // New DSL for framework configuration:
    framework {
        // All Framework properties are supported
        // Framework name configuration. Use this property instead of 
        // deprecated 'frameworkName'
        baseName = "MyFramework"
        // Dynamic framework support
        isStatic = false
        // Dependency export
        export(project(":anotherKMMModule"))
        transitiveExport = false // This is default.
        // Bitcode embedding
        embedBitcode(BITCODE)
    }
}

cocoapods {
    // Maps custom Xcode configuration to NativeBuildType
    xcodeConfigurationToNativeBuildType["CUSTOM_DEBUG"] = NativeBuildType.DEBUG
    xcodeConfigurationToNativeBuildType["CUSTOM_RELEASE"] = NativeBuildType.RELEASE
}

Экспериментальная взаимозаменяемость с Swift 5.5 async/await

Мы добавили поддержку вызова приостанавливающих функций Kotlin из Objective-C и Swift в 1.4.0, а теперь мы улучшаем ее, чтобы соответствовать новой функции Swift 5.5 — конкурентность с async и await модификаторами.

Компилятор Kotlin/Native теперь генерирует атрибут _Nullable_result в сгенерированных заголовках Objective-C для приостанавливающих функций с типом возвращаемого значения nullable. Это позволяет вызывать их из Swift как функции async с соответствующей nullable.

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

Улучшенное отображение Swift/Objective-C для объектов и компаньонов

Доступ к объектам и компаньонам теперь можно получить более интуитивно для разработчиков native iOS. Например, если у вас есть следующие объекты в Kotlin:

object MyObject {
    val x = "Some value"
}

class MyClass {
    companion object {
        val x = "Some value"
    }
}

Для доступа к ним в Swift вы можете использовать свойства shared и companion:

MyObject.shared
MyObject.shared.x
MyClass.companion
MyClass.Companion.shared

Узнайте больше о взаимозаменяемости Swift/Objective-C.

Устаревание связи с DLL без библиотек импорта для целей MinGW

LLD — это линковщик из проекта LLVM, который мы планируем использовать в Kotlin/Native для целей MinGW из-за его преимуществ перед стандартным ld.bfd — прежде всего, его лучшей производительности.

Однако последняя стабильная версия LLD не поддерживает прямую связь с DLL для целей MinGW (Windows). Для такой связи необходимо использовать библиотеки импорта. Хотя они не нужны с Kotlin/Native 1.5.30, мы добавляем предупреждение, чтобы проинформировать вас о том, что такое использование несовместимо с LLD, который станет стандартным линковщиком для MinGW в будущем.

Пожалуйста, поделитесь своими мыслями и опасениями по поводу перехода к линковщику LLD в этом вопросе YouTrack.

Возможность использования пользовательских библиотек cinterop в общем нативном коде

Kotlin Multiplatform предоставляет возможность использовать платформозависимые библиотеки межплатформенного взаимодействия в общих наборах исходного кода. До версии 1.5.30 это работало только с платформенными библиотеками, поставляемыми с дистрибутивом Kotlin/Native. Начиная с 1.5.30, вы можете использовать свои пользовательские cinterop библиотеки. Чтобы включить эту функцию, добавьте свойство kotlin.mpp.enableCInteropCommonization=true в свой gradle.properties:

kotlin.mpp.enableGranularSourceSetsMetadata=true
kotlin.native.enableDependencyPropagation=false
kotlin.mpp.enableCInteropCommonization=true

Поддержка XCFrameworks

Все проекты Kotlin Multiplatform теперь могут иметь XCFrameworks в качестве формата выходных данных. Apple представила XCFrameworks как замену универсальным (fat) фреймворкам. С помощью XCFrameworks вы:

• Можете объединить логику для всех целевых платформ и архитектур в одном пакете.

• Не нужно удалять все ненужные архитектуры перед публикацией приложения в App Store.

XCFrameworks полезно, если вы хотите использовать свой Kotlin фреймворк для устройств и симуляторов на Apple M1.

Чтобы использовать XCFrameworks, обновите свой скрипт build.gradle(.kts):

import org.jetbrains.kotlin.gradle.plugin.mpp.apple.XCFramework

plugins {
    kotlin("multiplatform")
}

kotlin {
    val xcf = XCFramework()
  
    ios {
        binaries.framework {
            baseName = "shared"
            xcf.add(this)
        }
    }
    watchos {
        binaries.framework {
            baseName = "shared"
            xcf.add(this)
        }
    }
    tvos {
        binaries.framework {
            baseName = "shared"
            xcf.add(this)
        }
    }
}

import org.jetbrains.kotlin.gradle.plugin.mpp.apple.XCFrameworkConfig

plugins {
    id 'org.jetbrains.kotlin.multiplatform'
}

kotlin {
    def xcf = new XCFrameworkConfig(project)

    ios {
        binaries.framework {
            baseName = "shared"
            xcf.add(it)
        }
    }
    watchos {
        binaries.framework {
            baseName = "shared"
            xcf.add(it)
        }
    }
    tvos {
        binaries.framework {
            baseName = "shared"
            xcf.add(it)
        }
    }
}

При объявлении XCFrameworks будут зарегистрированы новые задачи Gradle:

• assembleXCFramework

• assembleDebugXCFramework (дополнительный артефакт отладки, содержащий dSYMs)

• assembleReleaseXCFramework

Дополнительную информацию о XCFrameworks можно найти в этом видео WWDC.

Новая настройка публикации по умолчанию для артефактов Android

Используя плагин Gradle maven-publish, вы можете опубликовать свою многоплатформенную библиотеку для целевой платформы Android, указав имена вариантов Android в скрипте сборки. Плагин Kotlin Gradle сгенерирует публикации автоматически.

До версии 1.5.30 сгенерированный метаданные публикации metadata включал атрибуты типа сборки для каждого опубликованного варианта Android, что делало его совместимым только с тем же типом сборки, используемым потребителем библиотеки. Kotlin 1.5.30 вводит новую настройку публикации по умолчанию:

• Если все варианты Android, которые проект публикует, имеют одинаковый атрибут типа сборки, опубликованные варианты не будут содержать атрибут типа сборки и будут совместимы с любым типом сборки.

• Если опубликованные варианты имеют разные атрибуты типа сборки, будут опубликованы только те, которые имеют значение release, без атрибута типа сборки. Это делает версии релизов совместимыми с любым типом сборки на стороне потребителя, в то время как нерелизные варианты будут совместимы только с соответствующими типами сборок потребителя.

Чтобы отказаться от этого и сохранить атрибуты типа сборки для всех вариантов, можно установить это свойство Gradle: kotlin.android.buildTypeAttribute.keep=true.

Бета-версия компилятора JavaScript IR для Kotlin/JS

Основанный на IR компилятор для Kotlin/JS, который был представлен в 1.4.0 в Альфа-версии, достиг бета-стадии.

Ранее мы опубликовали руководство по миграции на JS IR backend, чтобы помочь вам мигрировать ваши проекты на новый backend. Теперь мы хотим представить плагин IDE Kotlin/JS Inspection Pack, который отображает необходимые изменения непосредственно в IntelliJ IDEA.

Улучшенный опыт отладки для приложений с Kotlin/JS IR backend

Kotlin 1.5.30 добавляет генерацию карт исходного кода JavaScript для Kotlin/JS IR backend. Это улучшит опыт отладки Kotlin/JS при включенном IR backend, с полной поддержкой отладки, включая точки останова, пошаговое выполнение и читаемые трассировки стека с правильными ссылками на исходный код.

Узнайте, как отлаживать Kotlin/JS в браузере или IntelliJ IDEA Ultimate.

Поддержка Java инструмент-цепочек

Gradle 6.7 представил функцию "Поддержка Java инструмент-цепочек". Используя эту функцию, вы можете:

• Выполнять компиляции, тесты и исполняемые файлы, используя JDK и JRE, отличные от тех, которые использует Gradle.

• Компилировать и тестировать код с невыпущенной версией языка.

С поддержкой инструмент-цепочек Gradle может автоматически обнаруживать локальные JDK и устанавливать недостающие JDK, необходимые Gradle для сборки. Теперь сам Gradle может работать с любым JDK и по-прежнему использовать функцию кэширования сборки.

Kotlin Gradle плагин поддерживает Java инструмент-цепочки для задач компиляции Kotlin/JVM. Java инструмент-цепь:

• Устанавливает значение параметра jdkHome, доступного для целей JVM.

• Устанавливает значение kotlinOptions.jvmTarget на версию JDK инструмент-цепи, если пользователь явно не установил параметр jvmTarget. Если инструмент-цепь не настроен, поле jvmTarget использует значение по умолчанию. Подробнее об совместимости JVM цели.

• Влияет на то, на каких JDK kapt worker выполняются.

Используйте следующий код для установки инструмент-цепи. Замените <MAJOR_JDK_VERSION> на версию JDK, которую вы хотите использовать:

kotlin {
    jvmToolchain {
        (this as JavaToolchainSpec).languageVersion.set(JavaLanguageVersion.of(<MAJOR_JDK_VERSION>)) // "8"
    }
}

kotlin {
    jvmToolchain {
        languageVersion.set(JavaLanguageVersion.of(<MAJOR_JDK_VERSION>)) // "8"
    }
}

Обратите внимание, что установка инструмент-цепи через расширение kotlin также обновит инструмент-цепь для задач компиляции Java.

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

java {
    toolchain {
        languageVersion.set(JavaLanguageVersion.of(<MAJOR_JDK_VERSION>)) // "8"
    }
}

Дополнительную информацию о настройке любой версии JDK для задач KotlinCompile см. в документации по установке версии JDK с помощью Task DSL.

Для версий Gradle от 6.1 до 6.6, используйте интерфейс UsesKotlinJavaToolchain для установки домашнего каталога JDK.

Возможность указать домашний каталог JDK с интерфейсом UsesKotlinJavaToolchain

Все задачи Kotlin, которые поддерживают установку JDK через kotlinOptions, теперь реализуют интерфейс UsesKotlinJavaToolchain. Для установки домашнего каталога JDK укажите путь к вашему JDK и замените <JDK_VERSION> на этот путь:

project.tasks
    .withType<UsesKotlinJavaToolchain>()
    .configureEach {
        it.kotlinJavaToolchain.jdk.use(
            "/path/to/local/jdk",
            JavaVersion.<LOCAL_JDK_VERSION>
        )
    }

project.tasks
    .withType(UsesKotlinJavaToolchain.class)
    .configureEach {
        it.kotlinJavaToolchain.jdk.use(
            '/path/to/local/jdk',
            JavaVersion.<LOCAL_JDK_VERSION>
        )
    }

Используйте интерфейс UsesKotlinJavaToolchain для версий Gradle от 6.1 до 6.6. Начиная с Gradle 6.7, используйте Java инструмент-цепочки.

При использовании этой функции обратите внимание, что kapt задачи worker будут использовать только режим изоляции процесса, а свойство kapt.workers.isolation будет игнорироваться.

Более простой способ явного указания аргументов JVM для Kotlin демона

В Kotlin 1.5.30 появилась новая логика для аргументов JVM Kotlin демона. Каждый из параметров в нижеследующем списке переопределяет предыдущие:

• Если ничего не указано, Kotlin демон наследует аргументы от Gradle демона (как и раньше). Например, в файле gradle.properties:

  org.gradle.jvmargs=-Xmx1500m -Xms=500m
  

• Если аргументы JVM Gradle демона имеют системную переменную kotlin.daemon.jvm.options, используйте её как и раньше:

  org.gradle.jvmargs=-Dkotlin.daemon.jvm.options=-Xmx1500m -Xms=500m
  

• Вы можете добавить свойство kotlin.daemon.jvmargs в файл gradle.properties:

  kotlin.daemon.jvmargs=-Xmx1500m -Xms=500m
  

• Вы можете указать аргументы в расширении kotlin:

  kotlin {
      kotlinDaemonJvmArgs = listOf("-Xmx486m", "-Xms256m", "-XX:+UseParallelGC")
  }
  

  kotlin {
      kotlinDaemonJvmArgs = ["-Xmx486m", "-Xms256m", "-XX:+UseParallelGC"]
  }
  

• Вы можете указать аргументы для конкретной задачи:

  tasks
      .matching { it.name == "compileKotlin" && it is CompileUsingKotlinDaemon }
      .configureEach {
          (this as CompileUsingKotlinDaemon).kotlinDaemonJvmArguments.set(listOf("-Xmx486m", "-Xms256m", "-XX:+UseParallelGC"))
      }
  

  tasks
      .matching {
          it.name == "compileKotlin" && it instanceof CompileUsingKotlinDaemon
      }
      .configureEach {
          kotlinDaemonJvmArguments.set(["-Xmx1g", "-Xms512m"])
      }
  

Дополнительную информацию о Kotlin демоне см. в документации о Kotlin демоне и его использовании с Gradle.

Изменение вывода Duration.toString()

До Kotlin 1.5.30 функция Duration.toString() возвращала строковое представление своего аргумента, выраженного в единицах, которые давали наиболее компактное и читаемое числовое значение. Отныне она будет возвращать строковое значение, выраженное как комбинацию числовых компонентов, каждый в своих собственных единицах. Каждый компонент — это число, за которым следует сокращённое имя единицы: d, h, m, s. Например:

Также изменён способ представления отрицательных продолжительностей. Отрицательная продолжительность предваряется знаком минус (-), а если она состоит из нескольких компонентов, то заключается в скобки: -12m и -(1h 30m).

Обратите внимание, что малые продолжительности менее одной секунды представлены как одно число с одной из единиц долей секунды. Например, ms (миллисекунды), us (микросекунды) или ns (наносекунды): 140.884ms, 500us, 24ns. Научная запись больше не используется для их представления.

Если вы хотите выразить продолжительность в одной единице, используйте перегруженную функцию Duration.toString(unit, decimals).

Парсинг Duration из строки

В Kotlin 1.5.30 появились новые функции в API Duration:

• parse(), которая поддерживает парсинг вывода функций:

  • toString().

  • toString(unit, decimals).

  • toIsoString().

• parseIsoString(), которая парсит только формат, созданный функцией toIsoString().

• parseOrNull() и parseIsoStringOrNull(), которые ведут себя подобно функциям выше, но возвращают null вместо того, чтобы выбрасывать IllegalArgumentException при некорректном формате продолжительности.

Вот несколько примеров использования parse() и parseOrNull():

import kotlin.time.Duration
import kotlin.time.ExperimentalTime

@ExperimentalTime
fun main() {
//sampleStart
    val isoFormatString = "PT1H30M"
    val defaultFormatString = "1h 30m"
    val singleUnitFormatString = "1.5h"
    val invalidFormatString = "1 hour 30 minutes"
    println(Duration.parse(isoFormatString)) // "1h 30m"
    println(Duration.parse(defaultFormatString)) // "1h 30m"
    println(Duration.parse(singleUnitFormatString)) // "1h 30m"
    //println(Duration.parse(invalidFormatString)) // throws exception
    println(Duration.parseOrNull(invalidFormatString)) // "null"
//sampleEnd
}

И вот несколько примеров использования parseIsoString() и parseIsoStringOrNull():

import kotlin.time.Duration
import kotlin.time.ExperimentalTime

@ExperimentalTime
fun main() {
//sampleStart
    val isoFormatString = "PT1H30M"
    val defaultFormatString = "1h 30m"
    println(Duration.parseIsoString(isoFormatString)) // "1h 30m"
    //println(Duration.parseIsoString(defaultFormatString)) // throws exception
    println(Duration.parseIsoStringOrNull(defaultFormatString)) // "null"
//sampleEnd
}

Сопоставление с регулярным выражением в определенной позиции

Новые функции Regex.matchAt() и Regex.matchesAt() позволяют проверить, есть ли точное совпадение регулярного выражения в определенной позиции в String или CharSequence.

Regex.matchAt() возвращает логическое значение:

fun main(){
//sampleStart
    val releaseText = "Kotlin 1.5.30 is released!"
    // regular expression: one digit, dot, one digit, dot, one or more digits
    val versionRegex = "\\d[.]\\d[.]\\d+".toRegex()
    println(versionRegex.matchesAt(releaseText, 0)) // "false"
    println(versionRegex.matchesAt(releaseText, 7)) // "true"
//sampleEnd
}

matchAt() возвращает совпадение, если оно найдено, или null, если нет:

fun main(){
//sampleStart
    val releaseText = "Kotlin 1.5.30 is released!"
    val versionRegex = "\\d[.]\\d[.]\\d+".toRegex()
    println(versionRegex.matchAt(releaseText, 0)) // "null"
    println(versionRegex.matchAt(releaseText, 7)?.value) // "1.5.30"
//sampleEnd
}

Разбиение регулярного выражения на последовательность

Новая функция Regex.splitToSequence() — это ленивый аналог split(). Она разбивает строку по совпадениям с заданным регулярным выражением, но возвращает результат в виде последовательности, чтобы все операции с этим результатом выполнялись лениво.

fun main(){
//sampleStart
    val colorsText = "green, red , brown&blue, orange, pink&green"
    val regex = "[,\\s]+".toRegex()
    val mixedColor = regex.splitToSequence(colorsText)
        .onEach { println(it) }
        .firstOrNull { it.contains('&') }
    println(mixedColor) // "brown&blue"
//sampleEnd
}

Аналогичная функция была также добавлена в CharSequence:

    val mixedColor = colorsText.splitToSequence(regex)