Что нового в 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 для включения этой функции. Обратите внимание, что все текущие ограничения для классов аннотаций, такие как ограничения на определение параметров, отличных от вторичных конструкторов, или членов, остаются в силе.

Узнайте больше о создании экземпляров классов аннотаций в этом 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 для приостанавливающих функций с необязательными возвращаемыми типами. Это позволяет вызывать их из Swift как async функции с соответствующей необязательностью.

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

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

Теперь доступ к объектам и компаньонам можно получить более интуитивно для разработчиков нативных 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 Многоплатформенность предоставляет вам возможность использования платформ-зависимых библиотек межплатформенного взаимодействия в общих наборах исходных кодов. До версии 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 Многоплатформенности теперь могут использовать 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 сгенерированные метаданные публикации включали атрибуты типа сборки для каждого опубликованного варианта Android, делая его совместимым только с тем же типом сборки, который используется потребителем библиотеки. Kotlin 1.5.30 вводит новую настройку публикации по умолчанию:

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

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

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

Бэкенд компилятора JS IR достигает стадии Beta

Базовый бэкенд компилятора на основе IR для Kotlin/JS, который был представлен в 1.4.0 в стадии Alpha, достиг стадии Beta.

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

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

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

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

Поддержка Java toolchains

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

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

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

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

Плагин Kotlin Gradle поддерживает Java toolchains для задач компиляции Kotlin/JVM. Java toolchain:

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

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

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

Используйте следующий код для установки toolchain. Замените заполнитель <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"
    }
}

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

Вы можете установить toolchain через расширение 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>
        )
    }

Для версий Gradle с 6.1 по 6.6 используйте интерфейс UsesKotlinJavaToolchain. Начиная с Gradle 6.7, используйте Java toolchains вместо этого.

При использовании этой функции обратите внимание, что рабочие процессы kapt будут использовать только режим изоляции процесса, и свойство 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 в определённой позиции

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

matchesAt() возвращает булевый результат:

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 на последовательность

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

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)