Что нового в Kotlin 1.8.0

Возможность не генерировать целевые аннотации TYPE_USE и TYPE_PARAMETER

Если Kotlin аннотация имеет TYPE среди своих Kotlin целей, аннотация отображается на java.lang.annotation.ElementType.TYPE_USE в списке Java целевых аннотаций. Это аналогично тому, как TYPE_PARAMETER Kotlin цель отображается на java.lang.annotation.ElementType.TYPE_PARAMETER Java целевую аннотацию. Это проблема для Android клиентов с уровнями API меньше 26, которые не имеют этих целей в API.

Начиная с Kotlin 1.8.0, вы можете использовать новую опцию компилятора -Xno-new-java-annotation-targets для избежания генерации TYPE_USE и TYPE_PARAMETER целевых аннотаций.

Новая опция компилятора для отключения оптимизаций

Kotlin 1.8.0 добавляет новую опцию компилятора -Xdebug, которая отключает оптимизации для улучшения опыта отладки. Пока эта опция отключает функцию «был оптимизирован» для сопроцедур. В будущем, после добавления дополнительных оптимизаций, эта опция также отключит их.

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

Удаление старого бэкенда

В Kotlin 1.5.0 мы сообщили, что бэкенд на основе IR стал стабильным. Это означало, что старый бэкенд из Kotlin 1.4.* был устаревшим. В Kotlin 1.8.0 мы полностью удалили старый бэкенд. Вследствие этого, мы удалили опцию компилятора -Xuse-old-backend и опцию Gradle useOldBackend.

Поддержка аннотации Lombok @Builder

Сообщество добавило множество голосов по вопросу Kotlin Lombok: Поддержка сгенерированных билдеров (@Builder) в YouTrack, поэтому мы просто должны поддержать @Builder аннотацию.

Пока у нас нет планов по поддержке аннотаций @SuperBuilder или @Tolerate, но мы пересмотрим это, если достаточно людей проголосуют за проблемы @SuperBuilder и @Tolerate.

Узнайте, как настроить плагин компилятора Lombok.

Поддержка Xcode 14.1

Компилятор Kotlin/Native теперь поддерживает последнюю стабильную версию Xcode, 14.1. Улучшения совместимости включают следующие изменения:

• Добавлен новый watchosDeviceArm64 предустановленный набор для целевой платформы watchOS, поддерживающий Apple watchOS на платформах ARM64.

• Плагин Kotlin CocoaPods Gradle больше не включает встраивание bitcode для фреймворков Apple по умолчанию.

• Библиотеки платформы были обновлены в соответствии с изменениями в фреймворках Objective-C для целевых платформ Apple.

Улучшенная межплатформенная работа Objective-C/Swift

Для повышения межплатформенной совместимости Kotlin с Objective-C и Swift были добавлены три новые аннотации:

• @ObjCName позволяет указать более понятное имя на Swift или Objective-C вместо переименования объявления Kotlin.

  Аннотация инструктирует компилятор Kotlin использовать пользовательское имя Objective-C и Swift для этого класса, свойства, параметра или функции:

  @ObjCName(swiftName = "MySwiftArray")
  class MyKotlinArray {
      @ObjCName("index")
      fun indexOf(@ObjCName("of") element: String): Int = TODO()
  }
  
  // Usage with the ObjCName annotations
  let array = MySwiftArray()
  let index = array.index(of: "element")
  

• @HiddenFromObjC позволяет скрыть объявление Kotlin от Objective-C.

  Аннотация инструктирует компилятор Kotlin не экспортировать функцию или свойство в Objective-C и, следовательно, в Swift. Это может сделать ваш код Kotlin более дружественным для Objective-C/Swift.

• @ShouldRefineInSwift полезна для замены объявления Kotlin оберточным кодом, написанным на Swift.

  Аннотация инструктирует компилятор Kotlin пометить функцию или свойство как swift_private в сгенерированном API Objective-C. Такие объявления получают префикс __, что делает их невидимыми для кода Swift.

  Вы по-прежнему можете использовать эти объявления в своем коде Swift для создания API, удобного для Swift, но они не будут предлагаться автодополнением Xcode, например.

  Для получения дополнительной информации об уточнении объявлений Objective-C в Swift, см. официальную документацию Apple.

Команда Kotlin выражает огромную благодарность Рику Клефасу за реализацию этих аннотаций.

Динамические фреймворки по умолчанию в плагине CocoaPods Gradle

Начиная с Kotlin 1.8.0, фреймворки Kotlin, зарегистрированные плагином CocoaPods Gradle, по умолчанию подключаются динамически. Предыдущая статическая реализация была несовместима с поведением плагина Kotlin Gradle.

kotlin {
    cocoapods {
        framework {
            baseName = "MyFramework"
            isStatic = false // Now dynamic by default
        }
    }
}

Если у вас есть существующий проект со статическим типом подключения и вы обновляетесь до Kotlin 1.8.0 (или явно меняете тип подключения), вы можете столкнуться с ошибкой выполнения проекта. Чтобы исправить ее, закройте проект Xcode и запустите pod install в каталоге Podfile.

Дополнительную информацию см. в справочнике по DSL плагина CocoaPods Gradle.

Схема именования KotlinSourceSet

{AndroidSourceSet.name} отображается на {KotlinSourceSet.name} следующим образом:

Директории наборов ресурсов

{AndroidSourceSet.name} отображается на {SourceDirectories included} следующим образом:

Расположение файла AndroidManifest.xml

{AndroidSourceSet.name} отображается на {AndroidManifest.xml location} следующим образом:

Взаимодействие между Android и общими тестами

Новая структура набора ресурсов Android изменяет взаимосвязь между Android-тестами (переименованными в androidInstrumentedTest в новой структуре) и общими тестами.

Ранее существовала стандартная dependsOn связь между androidAndroidTest и commonTest. На практике это означало следующее:

• Код в commonTest был доступен в androidAndroidTest.

• Объявления expect в commonTest должны были иметь соответствующие реализации actual в androidAndroidTest.

• Тесты, объявленные в commonTest также выполнялись как Android-тесты.

В новой структуре набора ресурсов Android эта dependsOn связь не добавляется по умолчанию. Если вы предпочитаете прежнее поведение, вручную объявите эту связь в вашем файле build.gradle.kts:

kotlin {
// ...
    sourceSets {
        val commonTest by getting
        val androidInstrumentedTest by getting {
            dependsOn(commonTest)
        }
    }
}

Поддержка Android-наборов ресурсов

Ранее плагин Kotlin Gradle с готовностью создавал наборы ресурсов, соответствующие Android-наборам ресурсов с типами сборки debug и release или настраиваемыми наборами ресурсов, такими как demo и full. Они были доступны с помощью конструкций, таких как val androidDebug by getting { ... }.

В новой структуре набора ресурсов Android эти наборы ресурсов создаются на стадии afterEvaluate Это делает такие выражения недействительными, что приводит к ошибкам, подобным org.gradle.api.UnknownDomainObjectException: KotlinSourceSet with name 'androidDebug' not found.

Для решения этой проблемы используйте новый API invokeWhenCreated() в вашем файле build.gradle.kts:

kotlin {
// ...
    sourceSets.invokeWhenCreated("androidFreeDebug") {
        // ...
    }
}

Настройка

Новая структура станет по умолчанию в будущих версиях. Вы можете включить её сейчас с помощью следующей опции Gradle:

kotlin.mpp.androidSourceSetLayoutVersion=2

Использование предыдущих каталогов в стиле Android не рекомендуется. Kotlin 1.8.0 отмечает начало процесса устаревания, вызывая предупреждение для текущей структуры. Вы можете подавить это предупреждение с помощью следующего свойства Gradle:

kotlin.mpp.androidSourceSetLayoutVersion1.nowarn=true

Стабильный бэкенд компилятора JS IR

Начиная с этого релиза, бэкенд компилятора Kotlin/JS промежуточного представления (IR-основанного) является стабильным. На унификацию инфраструктуры для всех трёх бэкендов потребовалось время, но теперь они работают с одним и тем же IR для кода Kotlin.

Вследствие стабильного бэкенда компилятора JS IR, старый бэкенд теперь устарел.

Инкрементная компиляция включена по умолчанию вместе со стабильным JS IR компилятором.

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

Новые настройки для отчётности об обновлении yarn.lock

Если вы используете менеджер пакетов yarn, есть три новые специальные настройки Gradle, которые могут уведомить вас, если файл yarn.lock был обновлён. Вы можете использовать эти настройки, когда хотите быть уведомлёнными, если yarn.lock был изменён в процессе сборки CI.

Эти три новые свойства Gradle:

• YarnLockMismatchReport, которое определяет, как будут сообщаться изменения в файле yarn.lock. Вы можете использовать одно из следующих значений:

  • FAIL — соответствующая задача Gradle завершается неудачно. Это значение по умолчанию.

  • WARNING — информация об изменениях записывается в журнал предупреждений.

  • NONE — отчётность отключена.

• reportNewYarnLock, которое явно сообщает об недавно созданном файле yarn.lock. По умолчанию этот параметр отключён: обычно новый файл yarn.lock генерируется при первом запуске. Вы можете использовать этот параметр, чтобы убедиться, что файл добавлен в ваш репозиторий.

• yarnLockAutoReplace, который автоматически заменяет yarn.lock каждый раз при выполнении задачи Gradle.

Чтобы использовать эти параметры, обновите свой файл скрипта сборки build.gradle.kts следующим образом:

import org.jetbrains.kotlin.gradle.targets.js.yarn.YarnLockMismatchReport
import org.jetbrains.kotlin.gradle.targets.js.yarn.YarnRootExtension

rootProject.plugins.withType(org.jetbrains.kotlin.gradle.targets.js.yarn.YarnPlugin::class.java) {
    rootProject.the<YarnRootExtension>().yarnLockMismatchReport =
        YarnLockMismatchReport.WARNING // NONE | FAIL
    rootProject.the<YarnRootExtension>().reportNewYarnLock = false // true
    rootProject.the<YarnRootExtension>().yarnLockAutoReplace = false // true
}

Добавление целей тестирования для браузеров через свойства Gradle

Начиная с Kotlin 1.8.0, вы можете задавать цели тестирования для разных браузеров прямо в файле свойств Gradle. Это сокращает размер файла скрипта сборки, так как вам больше не нужно писать все цели в build.gradle.kts.

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

Например, следующая строка в файле свойств Gradle запустит тесты в Firefox и Safari для всех модулей:

kotlin.js.browser.karma.browsers=firefox,safari

Полный список доступных значений для свойства на GitHub.

Команда Kotlin выражает благодарность Martynas Petuška за реализацию этой функции.

Новый подход к добавлению поддержки CSS в ваш проект

Этот релиз предлагает новый подход к добавлению поддержки CSS в ваш проект. Мы предполагаем, что это затронет много проектов, поэтому не забудьте обновить файлы скриптов сборки Gradle, как описано ниже.

До Kotlin 1.8.0, для добавления поддержки CSS использовалось свойство cssSupport.enabled.

browser {
    commonWebpackConfig {
        cssSupport.enabled = true
    }
}

Теперь вы должны использовать метод enabled.set() в блоке cssSupport {}:

browser {
    commonWebpackConfig {
        cssSupport {
            enabled.set(true)
        }
    }
}

Обновлённая целевая JVM-компиляция

В Kotlin 1.8.0 стандартные библиотеки (kotlin-stdlib, kotlin-reflect, и kotlin-script-*) скомпилированы с целевым JVM 1.8. Ранее стандартные библиотеки компилировались с целевым JVM 1.6.

Kotlin 1.8.0 больше не поддерживает JVM-целевые версии 1.6 и 1.7. В результате, вам больше не нужно объявлять kotlin-stdlib-jdk7 и kotlin-stdlib-jdk8 отдельно в скриптах сборки, так как содержимое этих артефактов объединены в kotlin-stdlib.

Обратите внимание, что смешивание различных версий артефактов stdlib может привести к дублированию классов или их отсутствию. Чтобы избежать этого, плагин Kotlin Gradle может помочь вам выровнять версии stdlib.

cbrt()

Функция cbrt(), позволяющая вычислить действительный кубический корень из double или float, теперь стабильна.

import kotlin.math.*

fun main() {
    val num = 27
    val negNum = -num

    println("The cube root of ${num.toDouble()} is: " +
            cbrt(num.toDouble()))
    println("The cube root of ${negNum.toDouble()} is: " +
            cbrt(negNum.toDouble()))
}

Преобразование единиц времени между Java и Kotlin

Функции toTimeUnit() и toDurationUnit() в kotlin.time теперь стабильны. Введённые как экспериментальные в Kotlin 1.6.0, эти функции улучшают взаимодействие между Kotlin и Java. Теперь вы можете легко преобразовывать между Java java.util.concurrent.TimeUnit и Kotlin kotlin.time.DurationUnit. Эти функции поддерживаются только на JVM.

import kotlin.time.*

// For use from Java
fun wait(timeout: Long, unit: TimeUnit) {
    val duration: Duration = timeout.toDuration(unit.toDurationUnit())
    ...
}

Сравнимые и вычитаемые отметки времени

До Kotlin 1.8.0, если вы хотели вычислить разницу во времени между несколькими TimeMarks и текущим моментом, вы могли вызывать elapsedNow() только для одной TimeMark за раз. Это затрудняло сравнение результатов, так как два вызова функции elapsedNow() не могли быть выполнены в точности одновременно.

Для решения этой проблемы в Kotlin 1.8.0 вы можете вычитать и сравнивать TimeMarks из одного и того же источника времени. Теперь вы можете создать новый экземпляр TimeMark для представления текущего момента и вычитать другие TimeMarks из него. Таким образом, результаты, которые вы собираете из этих вычислений, гарантированно будут относительны друг к другу.

import kotlin.time.*
fun main() {
//sampleStart
    val timeSource = TimeSource.Monotonic
    val mark1 = timeSource.markNow()
    Thread.sleep(500) // Sleep 0.5 seconds
    val mark2 = timeSource.markNow()

    // Before 1.8.0
    repeat(4) { n ->
        val elapsed1 = mark1.elapsedNow()
        val elapsed2 = mark2.elapsedNow()

        // Difference between elapsed1 and elapsed2 can vary depending 
        // on how much time passes between the two elapsedNow() calls
        println("Measurement 1.${n + 1}: elapsed1=$elapsed1, " +
                "elapsed2=$elapsed2, diff=${elapsed1 - elapsed2}")
    }
    println()

    // Since 1.8.0
    repeat(4) { n ->
        val mark3 = timeSource.markNow()
        val elapsed1 = mark3 - mark1
        val elapsed2 = mark3 - mark2

        // Now the elapsed times are calculated relative to mark3, 
        // which is a fixed value
        println("Measurement 2.${n + 1}: elapsed1=$elapsed1, " +
                "elapsed2=$elapsed2, diff=${elapsed1 - elapsed2}")
    }
    // It's also possible to compare time marks with each other
    // This is true, as mark2 was captured later than mark1
    println(mark2 > mark1)
//sampleEnd
}

Эта новая функциональность особенно полезна при расчётах анимации, когда вы хотите вычислить разницу или сравнить несколько TimeMarks , представляющие разные кадры.

Рекурсивное копирование или удаление каталогов

Мы представили две новые расширяющие функции для java.nio.file.Path, copyToRecursively() и deleteRecursively(), которые позволяют вам рекурсивно:

• Скопировать каталог и его содержимое в другое место назначения.

• Удалить каталог и его содержимое.

Эти функции могут быть очень полезны в рамках процесса резервного копирования.

sourceRoot.copyToRecursively(destinationRoot, followLinks = false,
    onError = { source, target, exception ->
        logger.logError(exception, "Failed to copy $source to $target")
        OnErrorResult.TERMINATE
    })

fun setUpEnvironment(projectDirectory: Path, fixtureName: String) {
    fixturesRoot.resolve(COMMON_FIXTURE_NAME)
        .copyToRecursively(projectDirectory, followLinks = false)
    fixturesRoot.resolve(fixtureName)
        .copyToRecursively(projectDirectory, followLinks = false,
            overwrite = true) // patches the common fixture
}

sourceRoot.copyToRecursively(destinationRoot, followLinks = false) { source, target ->
    if (source.name.startsWith(".")) {
        CopyActionResult.SKIP_SUBTREE
    } else {
        source.copyToIgnoringExistingDirectory(target, followLinks = false)
        CopyActionResult.CONTINUE
    }
}

Расширяющие функции для Java Optional

Расширяющие функции, представленные в Kotlin 1.7.0, теперь стабильны. Эти функции упрощают работу с классами Optional в Java. Они могут быть использованы для распаковки и преобразования Optional объектов на JVM и для более лаконичной работы с Java API. Дополнительную информацию см. в Что нового в Kotlin 1.7.0.

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

Используя тот факт, что kotlin-reflect теперь компилируется с целевой JVM 1.8, мы мигрировали нашу внутреннюю механизм кэширования на Java ClassValue. Ранее мы кэшировали только KClass, но теперь мы также кэшируем KType и KDeclarationContainer. Эти изменения привели к значительному улучшению производительности при вызове typeOf().

Переработанные и новые страницы

• Обзор Gradle – узнайте, как настроить и собрать проект Kotlin с помощью Gradle, доступные опции компилятора, компиляция и кэширование в плагине Kotlin Gradle.

• Использование nullable-типов в Java и Kotlin – рассмотрите различия между подходами Java и Kotlin к обработке переменных, которые могут быть null.

• Руководство по Lincheck – узнайте, как настроить и использовать фреймворк Lincheck для тестирования конкурирующих алгоритмов на JVM.

Новые и обновлённые учебники

• Начало работы с Gradle и Kotlin/JVM – создание консольного приложения с помощью IntelliJ IDEA и Gradle.

• Создание кроссплатформенного приложения с использованием Ktor и SQLDelight – создание мобильного приложения для iOS и Android с помощью Kotlin Multiplatform Mobile.

• Начало работы с Kotlin Multiplatform Mobile – изучите кроссплатформенную разработку мобильных приложений с помощью Kotlin и создайте приложение, работающее как на Android, так и на iOS.