Что нового в Kotlin 1.4.0

Преобразования SAM для Kotlin-интерфейсов

До Kotlin 1.4.0 преобразования SAM (Single Abstract Method) можно было применять только при работе с Java-методами и Java-интерфейсами из Kotlin. Теперь вы можете использовать преобразования SAM для Kotlin-интерфейсов. Для этого пометьте Kotlin-интерфейс явно как функциональный с помощью fun модификатора.

Преобразование SAM применяется, если в качестве аргумента передается лямбда-выражение, когда в качестве параметра ожидается интерфейс с единственным абстрактным методом. В этом случае компилятор автоматически преобразует лямбда-выражение в экземпляр класса, реализующего абстрактный член функции.

fun interface IntPredicate {
    fun accept(i: Int): Boolean
}

val isEven = IntPredicate { it % 2 == 0 }

fun main() { 
    println("Is 7 even? - ${isEven.accept(7)}")
}

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

Режим явного API для авторов библиотек

Компилятор Kotlin предлагает режим явного API для авторов библиотек. В этом режиме компилятор выполняет дополнительные проверки, которые помогают сделать API библиотеки более понятным и согласованным. Он добавляет следующие требования к объявлениям, доступным для публичного API библиотеки:

• Требуются модификаторы видимости для объявлений, если по умолчанию они доступны в публичном API. Это помогает гарантировать, что ни одно объявление не будет случайно доступно для публичного API.

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

В зависимости от вашей конфигурации, эти явные API могут генерировать ошибки (строгий режим) или предупреждения (режим предупреждения). Некоторые типы объявлений исключаются из таких проверок ради удобочитаемости и здравого смысла:

• первичные конструкторы

• свойства классов данных

• геттеры и сеттеры свойств

• override методы

Режим явного API анализирует только исходные файлы модуля.

Для компиляции модуля в режиме явного API добавьте следующие строки в ваш скрипт сборки Gradle:

kotlin {    
    // for strict mode
    explicitApi() 
    // or
    explicitApi = ExplicitApiMode.Strict
    
    // for warning mode
    explicitApiWarning()
    // or
    explicitApi = ExplicitApiMode.Warning
}

kotlin {    
    // for strict mode
    explicitApi() 
    // or
    explicitApi = 'strict'
    
    // for warning mode
    explicitApiWarning()
    // or
    explicitApi = 'warning'
}

При использовании компилятора командной строки переключитесь на режим явного API, добавив -Xexplicit-api параметр компилятора со значением strict или warning.

-Xexplicit-api={strict|warning}

Дополнительные сведения о режиме явного API см. в KEEP.

Смешивание именованных и позиционных аргументов

В Kotlin 1.3, когда вы вызывали функцию с именованными аргументами, вам нужно было поместить все аргументы без имен (позиционные аргументы) перед первым именованным аргументом. Например, вы могли вызвать f(1, y = 2), но не могли вызвать f(x = 1, 2).

Это было действительно раздражающим, когда все аргументы были на своих местах, но вы хотели указать имя для одного аргумента посередине. Это особенно полезно для того, чтобы абсолютно четко указать, к какому атрибуту относится значение boolean или null.

В Kotlin 1.4 такого ограничения нет — теперь вы можете указать имя аргумента посередине набора позиционных аргументов. Кроме того, вы можете смешивать позиционные и именованные аргументы любым способом, при условии, что они сохраняют правильный порядок.

fun reformat(
    str: String,
    uppercaseFirstLetter: Boolean = true,
    wordSeparator: Char = ' '
) {
    // ...
}

//Function call with a named argument in the middle
reformat("This is a String!", uppercaseFirstLetter = false , '-')

Завершающая запятая

В Kotlin 1.4 теперь можно добавлять завершающую запятую в списки аргументов и параметров, when записи и компоненты деструктурирующих объявлений. С завершающей запятой вы можете добавлять новые элементы и изменять их порядок без добавления или удаления запятых.

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

fun reformat(
    str: String,
    uppercaseFirstLetter: Boolean = true,
    wordSeparator: Character = ' ', //trailing comma
) {
    // ...
}

val colors = listOf(
    "red",
    "green",
    "blue", //trailing comma
)

Улучшения вызываемых ссылок

Kotlin 1.4 поддерживает больше случаев использования вызываемых ссылок:

• Ссылки на функции с значениями по умолчанию

• Ссылки на функции в Unit-возвращающих функциях

• Ссылки, которые адаптируются в зависимости от количества аргументов в функции

• Преобразование suspend для вызываемых ссылок

fun foo(i: Int = 0): String = "$i!"

fun apply(func: () -> String): String = func()

fun main() {
    println(apply(::foo))
}

// some new overload
fun applyInt(func: (Int) -> String): String = func(0) 

fun foo(f: () -> Unit) { }
fun returnsInt(): Int = 42

fun main() {
    foo { returnsInt() } // this was the only way to do it  before 1.4
    foo(::returnsInt) // starting from 1.4, this also works
}

fun foo(x: Int, vararg y: String) {}

fun use0(f: (Int) -> Unit) {}
fun use1(f: (Int, String) -> Unit) {}
fun use2(f: (Int, String, String) -> Unit) {}

fun test() {
    use0(::foo) 
    use1(::foo) 
    use2(::foo) 
}

fun call() {}
fun takeSuspend(f: suspend () -> Unit) {}

fun test() {
    takeSuspend { call() } // OK before 1.4
    takeSuspend(::call) // In Kotlin 1.4, it also works
}

Использование break и continue внутри выражений when, включенных в циклы

В Kotlin 1.3 вы не могли использовать неквалифицированные break и continue внутри when выражений, включенных в циклы. Причина заключалась в том, что эти ключевые слова были зарезервированы для возможного продолжения выполнения в when выражениях.

Поэтому, если вы хотели использовать break и continue внутри when выражений в циклах, вам приходилось помечать их, что становилось довольно громоздким.

fun test(xs: List<Int>) {
    LOOP@for (x in xs) {
        when (x) {
            2 -> continue@LOOP
            17 -> break@LOOP
            else -> println(x)
        }
    }
}

В Kotlin 1.4 вы можете использовать break и continue без меток внутри when выражений, включенных в циклы. Они ведут себя так, как ожидается, завершая ближайший внешний цикл или переходя к его следующей итерации.

fun test(xs: List<Int>) {
    for (x in xs) {
        when (x) {
            2 -> continue
            17 -> break
            else -> println(x)
        }
    }
}

Поведение продолжения выполнения внутри when находится на стадии дальнейшей разработки.

Новый гибкий мастер проектов

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

Новый мастер проектов Kotlin прост и гибкий:

1. Выберите шаблон проекта в зависимости от того, что вы хотите сделать. В будущем будет добавлено больше шаблонов.

2. Выберите систему сборки – Gradle (Kotlin или Groovy DSL), Maven или IntelliJ IDEA.
   Мастер проектов Kotlin будет отображать только поддерживаемые системы сборки для выбранного шаблона проекта.

3. Предварительный просмотр структуры проекта непосредственно на главном экране.

Затем вы можете завершить создание проекта или, по желанию, настроить проект на следующем экране:

4. Добавить/удалить модули и целевые платформы, поддерживаемые для этого шаблона проекта.

5. Настройка параметров модуля и целевой платформы, например, версия целевой JVM, шаблон цели и фреймворк для тестирования.

В будущем мы планируем сделать мастер проектов Kotlin еще более гибким, добавив больше параметров настройки и шаблонов.

Вы можете опробовать новый мастер проектов Kotlin, выполнив эти руководства:

• Создание консольного приложения на основе Kotlin/JVM

• Создание приложения Kotlin/JS для React

• Создание приложения Kotlin/Native

Отладчик корутин

Многие уже используют корутины для асинхронного программирования. Но когда дело доходило до отладки, работа с корутинами до Kotlin 1.4 была довольно сложной. Поскольку корутины перепрыгивали между потоками, было сложно понять, что делает конкретная корутина и проверить ее контекст. В некоторых случаях отслеживание шагов через точки останова просто не работало. В результате приходилось полагаться на логирование или умственные усилия для отладки кода, использующего корутины.

В Kotlin 1.4 отладка корутин стала намного удобнее благодаря новым функциям, поставляемым с плагином Kotlin.

Окно инструментов отладки теперь содержит новую вкладку Корутины. В этой вкладке вы можете найти информацию о текущих и приостановленных корутинах. Корутины сгруппированы по диспетчеру, на котором они выполняются.

Теперь вы можете:

• Легко проверять состояние каждой корутины.

• Просматривать значения локальных и захваченных переменных для как выполняемых, так и приостановленных корутин.

• Просматривать полный стек создания корутины, а также стек вызовов внутри корутины. Стек включает все фреймы с значениями переменных, даже те, которые терялись во время стандартной отладки.

Если вам нужен полный отчет, содержащий состояние каждой корутины и ее стек, щелкните правой кнопкой мыши внутри вкладки Корутины, а затем нажмите Получить дамп корутин. В настоящее время дамп корутин довольно прост, но мы сделаем его более читаемым и полезным в будущих версиях Kotlin.

Узнайте больше об отладке корутин в этой статье блога и документации IntelliJ IDEA.

Новый более мощный алгоритм вывода типов

Kotlin 1.4 использует новый, более мощный алгоритм вывода типов. Этот новый алгоритм уже был доступен для тестирования в Kotlin 1.3 путём указания параметра компилятора, и теперь он используется по умолчанию. Полный список исправленных проблем в новом алгоритме можно найти в YouTrack. Здесь вы можете найти некоторые из самых заметных улучшений:

• Больше случаев, когда тип выводится автоматически

• Умные преобразования типов для последнего выражения лямбда-выражения

• Умные преобразования типов для вызываемых ссылок

• Улучшенный вывод типов для делегированных свойств

• Преобразование SAM для интерфейсов Java с различными аргументами

• Интерфейсы Java SAM в Kotlin

//sampleStart
val rulesMap: Map<String, (String?) -> Boolean> = mapOf(
    "weak" to { it != null },
    "medium" to { !it.isNullOrBlank() },
    "strong" to { it != null && "^[a-zA-Z0-9]+$".toRegex().matches(it) }
)
//sampleEnd

fun main() {
    println(rulesMap.getValue("weak")("abc!"))
    println(rulesMap.getValue("strong")("abc"))
    println(rulesMap.getValue("strong")("abc!"))
}

val result = run {
    var str = currentValue()
    if (str == null) {
        str = "test"
    }
    str // the Kotlin compiler knows that str is not null here
}
// The type of 'result' is String? in Kotlin 1.3 and String in Kotlin 1.4

import kotlin.reflect.KFunction

sealed class Animal
class Cat : Animal() {
    fun meow() {
        println("meow")
    }
}

class Dog : Animal() {
    fun woof() {
        println("woof")
    }
}

//sampleStart
fun perform(animal: Animal) {
    val kFunction: KFunction<*> = when (animal) {
        is Cat -> animal::meow
        is Dog -> animal::woof
    }
    kFunction.call()
}
//sampleEnd

fun main() {
    perform(Cat())
}

import kotlin.properties.Delegates

fun main() {
    var prop: String? by Delegates.observable(null) { p, old, new ->
        println("$old → $new")
    }
    prop = "abc"
    prop = "xyz"
}

// FILE: A.java
public class A {
    public static void foo(Runnable r1, Runnable r2) {}
}

// FILE: test.kt
fun test(r1: Runnable) {
    A.foo(r1) {}  // Works in Kotlin 1.4
}

import java.lang.Runnable

fun foo(r: Runnable) {}

fun test() { 
    foo { } // OK
}

Объединённые бэкэнды и расширяемость

В Kotlin у нас есть три бэкэнда, которые генерируют исполняемые файлы: Kotlin/JVM, Kotlin/JS и Kotlin/Native. Kotlin/JVM и Kotlin/JS не имеют много общего кода, поскольку они разрабатывались независимо друг от друга. Kotlin/Native основан на новой инфраструктуре, построенной вокруг промежуточного представления (IR) для кода Kotlin.

Сейчас мы мигрируем Kotlin/JVM и Kotlin/JS в одно и то же IR. В результате все три бэкэнда разделяют много логики и имеют унифицированную конвейерную линию. Это позволяет нам реализовывать большинство функций, оптимизаций и исправлений ошибок только один раз для всех платформ. Оба новых бэкэнда на основе IR находятся в стадии Альфа.

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

Мы рекомендуем использовать новые бэкэнды JVM IR и JS IR, которые в настоящее время находятся в стадии Альфа, и поделиться своими отзывами с нами.

Новый бэкенд JVM IR

Вместе с Kotlin/JS мы мигрируем Kotlin/JVM на унифицированный бэкенд IR, что позволяет нам реализовывать большинство функций и исправлять ошибки один раз для всех платформ. Вы также сможете извлечь выгоду из этого, создавая кроссплатформенные расширения, которые будут работать на всех платформах.

Kotlin 1.4.0 пока не предоставляет публичный API для таких расширений, но мы тесно сотрудничаем с нашими партнёрами, включая Jetpack Compose, которые уже создают свои плагины компилятора, используя наш новый бэкенд.

Мы рекомендуем вам опробовать новый бэкенд Kotlin/JVM, который сейчас находится в стадии альфа-версии, и сообщить о любых проблемах и пожеланиях по функциям в наш трекер задач. Это поможет нам унифицировать конвейеры компилятора и быстрее интегрировать расширения компилятора, такие как Jetpack Compose, в сообщество Kotlin.

Для активации нового бэкенда JVM IR укажите дополнительный параметр компилятора в вашем файле Gradle:

kotlinOptions.useIR = true

При использовании компилятора командной строки добавьте параметр компилятора -Xuse-ir.

Новые режимы генерации методов по умолчанию

При компиляции кода Kotlin для целей JVM 1.8 и выше, вы могли компилировать неабстрактные методы Kotlin-интерфейсов в методы Java default. Для этой цели существовал механизм, включающий аннотацию @JvmDefault, чтобы отмечать такие методы, и параметр компилятора -Xjvm-default, который активировал обработку этой аннотации.

В версии 1.4.0 мы добавили новый режим генерации методов по умолчанию: -Xjvm-default=all компилирует все неабстрактные методы Kotlin-интерфейсов в методы Java default. Для совместимости с кодом, использующим интерфейсы, скомпилированные без default, мы также добавили режим all-compatibility.

Дополнительную информацию о методах по умолчанию в Java-взаимодействии см. в документации по взаимодействию и этой статье блога.

Единый тип исключения для проверок на null

Начиная с Kotlin 1.4.0, все проверки на null во время выполнения будут выбрасывать исключение java.lang.NullPointerException вместо KotlinNullPointerException, IllegalStateException, IllegalArgumentException, и TypeCastException. Это относится к: оператору !!, проверкам параметров на null в преамбуле метода, проверкам на null платформенно-типизированных выражений и оператору as с типом не null. Это не относится к lateinit проверкам на null и явным вызовам функций библиотек, таким как checkNotNull или requireNotNull.

Это изменение увеличивает количество возможных оптимизаций проверок на null, которые могут быть выполнены либо Kotlin-компилятором, либо различными инструментами обработки байткода, такими как оптимизатор R8 Android Android.

Обратите внимание, что с точки зрения разработчика, изменения будут не очень значительными: код Kotlin будет выбрасывать исключения с теми же сообщениями об ошибках, что и раньше. Тип исключения меняется, но передаваемая информация остаётся той же.

Аннотации типов в байткоде JVM

Kotlin теперь может генерировать аннотации типов в байткоде JVM (версия целевого языка 1.8+), так что они станут доступны в Java-рефлексии во время выполнения. Для генерации аннотации типа в байткоде выполните следующие действия:

1. Убедитесь, что ваша объявленная аннотация имеет правильную цель применения аннотации (Java's ElementType.TYPE_USE или Kotlin's AnnotationTarget.TYPE ) и сохранность (AnnotationRetention.RUNTIME).

2. Скомпилируйте объявление класса аннотации в байткод JVM с целевой версией 1.8+. Вы можете указать её с помощью параметра компилятора -jvm-target=1.8.

3. Скомпилируйте код, использующий аннотацию, в байткод JVM с целевой версией 1.8+ (-jvm-target=1.8) и добавьте параметр компилятора -Xemit-jvm-type-annotations.

Обратите внимание, что аннотации типа из стандартной библиотеки пока не генерируются в байткоде, так как стандартная библиотека скомпилирована с целевой версией 1.6.

Пока поддерживаются только базовые случаи:

• Аннотации типа на параметрах методов, типах возвращаемых значений методов и типах свойств;

• Инвариантные проекции аргументов типа, такие как Smth<@Ann Foo>, Array<@Ann Foo>.

В следующем примере аннотация @Foo на типе String может быть сгенерирована в байткоде и затем использована кодом библиотеки:

@Target(AnnotationTarget.TYPE)
annotation class Foo

class A {
    fun foo(): @Foo String = "OK"
}

Новая Gradle DSL

Плагин Gradle kotlin.js поставляется с изменённой Gradle DSL, которая предоставляет ряд новых параметров конфигурации и более точно соответствует DSL, используемому плагином kotlin-multiplatform. Некоторые из самых важных изменений включают:

• Явные переключатели для создания исполняемых файлов с помощью binaries.executable(). Подробнее об исполнении Kotlin/JS и его среде здесь.

• Конфигурация CSS- и стилистических загрузчиков webpack внутри конфигурации Gradle с помощью cssSupport. Подробнее об использовании CSS- и стилистических загрузчиков здесь.

• Улучшенное управление зависимостями npm, с обязательными версиями или диапазонами версий semver, а также поддержка разработки, зависимостей и дополнительных зависимостей npm с помощью devNpm, optionalNpm и peerNpm. Подробнее об управлении зависимостями npm пакетов прямо из Gradle здесь.

• Более сильные интеграции с Dukat, генератором внешних объявлений Kotlin. Внешние объявления теперь могут генерироваться во время сборки или генерироваться вручную с помощью задачи Gradle.

Новый бэкенд JS IR

Бэкенд IR для Kotlin/JS, который в настоящее время имеет Альфа стабильность, предоставляет некоторые новые функции, специфичные для целевого языка Kotlin/JS, которые сосредоточены на размере генерируемого кода через удаление мертвого кода, улучшенное взаимодействие с JavaScript и TypeScript и другие.

Для активации бэкенда Kotlin/JS IR установите ключ kotlin.js.compiler=ir в вашей gradle.properties, или передайте тип компилятора IR в функцию js вашего файла Gradle:

kotlin {
    js(IR) { // or: LEGACY, BOTH
        // ...
    }
    binaries.executable()
}

Более подробную информацию о настройке нового бэкенда см. в документации компилятора Kotlin/JS IR.

Благодаря новой аннотации @JsExport и возможности генерации определений TypeScript из кода Kotlin, бэкенд компилятора Kotlin/JS IR улучшает взаимодействие JavaScript и TypeScript. Это также упрощает интеграцию кода Kotlin/JS с существующими инструментами, для создания гибридных приложений и использования функциональности совместного использования кода в кроссплатформенных проектах.

Узнайте больше о доступных функциях бэкенда компилятора Kotlin/JS IR.

Поддержка приостанавливаемых функций Kotlin в Swift и Objective-C

В версии 1.4.0 мы добавили базовую поддержку приостанавливаемых функций в Swift и Objective-C. Теперь, когда вы компилируете модуль Kotlin в Apple фреймворк, приостанавливаемые функции доступны в нём как функции с обратными вызовами (completionHandler в терминологии Swift/Objective-C). Когда у вас есть такие функции в заголовке сгенерированного фреймворка, вы можете вызывать их из своего Swift или Objective-C кода, а также переопределять их.

Например, если вы напишете эту функцию Kotlin:

suspend fun queryData(id: Int): String = ...

...то вы можете вызвать её из Swift следующим образом:

queryData(id: 17) { result, error in
   if let e = error {
       print("ERROR: \(e)")
   } else {
       print(result!)
   }
}

Узнайте больше о работе с приостанавливаемыми функциями в Swift и Objective-C.

Поддержка Objective-C дженериков по умолчанию

Предыдущие версии Kotlin предоставляли экспериментальную поддержку дженериков в Objective-C взаимодействии. С версии 1.4.0 Kotlin/Native генерирует Apple фреймворки с дженериками из Kotlin кода по умолчанию. В некоторых случаях это может нарушить существующий Objective-C или Swift код, вызывающий Kotlin фреймворки. Чтобы заголовок фреймворка был написан без дженериков, добавьте опцию компилятора -Xno-objc-generics.

kotlin {
    targets.withType<org.jetbrains.kotlin.gradle.plugin.mpp.KotlinNativeTarget> {
        binaries.all {
            freeCompilerArgs += "-Xno-objc-generics"
        }
    }
}

Пожалуйста, обратите внимание, что все подробности и ограничения, указанные в документации по взаимодействию с Objective-C, по-прежнему актуальны.

Обработка исключений в Objective-C/Swift взаимодействии

В версии 1.4.0 мы немного изменили Swift API, сгенерированный из Kotlin, в отношении способа преобразования исключений. Существует фундаментальное различие в обработке ошибок между Kotlin и Swift. Все исключения Kotlin не проверяемые, в то время как Swift имеет только проверяемые ошибки. Таким образом, чтобы код Swift знал об ожидаемых исключениях, функции Kotlin должны быть помечены аннотацией @Throws, указывающей список потенциальных классов исключений.

При компиляции в Swift или Objective-C фреймворк функции, которые имеют или наследуют аннотацию @Throws, представляются как методы, генерирующие NSError* в Objective-C и как throws методы в Swift.

Ранее любые исключения, кроме RuntimeException и Error, передавались как NSError. Теперь это поведение изменяется: теперь NSError выбрасывается только для исключений, которые являются экземплярами классов, указанных в качестве параметров аннотации @Throws (или их подклассов). Другие Kotlin исключения, которые достигают Swift/Objective-C, считаются необработанными и приводят к завершению программы.

Генерация release .dSYMs по умолчанию для Apple целей

Начиная с версии 1.4.0, компилятор Kotlin/Native по умолчанию производит файлы символов отладки (.dSYMs) для релизных бинарников на платформах Darwin. Это можно отключить с помощью опции компилятора -Xadd-light-debug=disable. На других платформах эта опция отключена по умолчанию. Чтобы переключить эту опцию в Gradle, используйте:

kotlin {
    targets.withType<org.jetbrains.kotlin.gradle.plugin.mpp.KotlinNativeTarget> {
        binaries.all {
            freeCompilerArgs += "-Xadd-light-debug={enable|disable}"
        }
    }
}

Узнайте больше об отображении отчетов о сбоях.

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

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

• Для повышения скорости выделения объектов мы теперь предлагаем выделение памяти mimalloc в качестве альтернативы системному выделению. mimalloc работает до двух раз быстрее на некоторых бенчмарках. В настоящее время использование mimalloc в Kotlin/Native экспериментально; вы можете переключиться на него, используя опцию компилятора -Xallocator=mimalloc.

• Мы переработали способ сборки библиотек C-взаимодействия. С новым инструментом Kotlin/Native производит библиотеки взаимодействия до 4 раз быстрее, чем раньше, а артефакты составляют от 25% до 30% от своего первоначального размера.

• Общая производительность во время выполнения улучшилась благодаря оптимизациям в GC. Это улучшение будет особенно заметно в проектах с большим количеством долгоживущих объектов. HashMap и HashSet коллекции теперь работают быстрее благодаря устранению лишнего боксинга.

• В 1.3.70 мы добавили две новые функции для повышения производительности компиляции Kotlin/Native: кеширование зависимостей проекта и запуск компилятора из демона Gradle. С тех пор мы исправили многочисленные ошибки и улучшили общую стабильность этих функций.

Упрощённое управление зависимостями CocoaPods

Ранее, после интеграции вашего проекта с менеджером зависимостей CocoaPods, вы могли собирать iOS, macOS, watchOS или tvOS часть вашего проекта только в Xcode, отдельно от других частей вашего кроссплатформенного проекта. Эти другие части можно было собирать в IntelliJ IDEA.

Кроме того, каждый раз, когда вы добавляли зависимость от Objective-C библиотеки, хранящейся в CocoaPods (библиотека Pod), вам приходилось переключаться с IntelliJ IDEA на Xcode, вызывать pod install, и запускать сборку Xcode там.

Теперь вы можете управлять зависимостями Pod прямо в IntelliJ IDEA, наслаждаясь преимуществами, которые он предоставляет для работы с кодом, такими как подсветка синтаксиса и автодополнение. Вы также можете собрать весь Kotlin проект с помощью Gradle, не переключаясь на Xcode. Это означает, что вам нужно переходить в Xcode только тогда, когда вам нужно написать код Swift/Objective-C или запустить ваше приложение на эмуляторе или устройстве.

Теперь вы также можете работать с Pod библиотеками, хранящимися локально.

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

• Kotlin проектом и Pod библиотеками, хранящимися удалённо в репозитории CocoaPods или локально на вашем компьютере.

• Kotlin Pod (Kotlin проект, используемый в качестве CocoaPods зависимости) и Xcode проектом с одним или несколькими целевыми приложениями.

Завершите начальную настройку, и когда вы добавите новую зависимость в cocoapods, просто повторно импортируйте проект в IntelliJ IDEA. Новая зависимость будет добавлена автоматически. Дополнительные шаги не требуются.

Узнайте, как добавить зависимости.

Общий код для нескольких целей с иерархической структурой проекта

Благодаря поддержке новой иерархической структуры проекта вы можете использовать общий код между несколькими платформами в многоплатформенном проекте.

Ранее любой код, добавленный в многоплатформенный проект, мог быть размещен либо в наборе исходного кода, специфичного для платформы, ограниченного одной целью и непереиспользуемого другой платформой, либо в общем наборе исходного кода, например, commonMain или commonTest, который используется на всех платформах в проекте. В общем наборе исходного кода вы могли вызывать API, специфичный для платформы, только с помощью expect объявления, которое требует платформа-специфических actual реализаций.

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

Например, в типичном многоплатформенном проекте, нацеленном на iOS, есть две цели, связанные с iOS: одна для устройств iOS ARM64 и другая для симулятора x64. У них есть отдельные наборы исходного кода, специфичные для платформы, но на практике редко возникает необходимость в разном коде для устройства и симулятора, а их зависимости очень похожи. Поэтому код, специфичный для iOS, мог бы использоваться между ними.

По всей видимости, в этой настройке было бы желательно иметь общий набор исходного кода для двух целей iOS с Kotlin/Native-кодом, который по-прежнему мог бы напрямую вызывать любые API, общие для устройства iOS и симулятора.

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

Для распространенных комбинаций целей вы можете создать иерархическую структуру с ярлыками для целей.

Например, создайте две цели iOS и общий набор исходного кода, показанный выше, с ярлыком для целей ios().

kotlin {
    ios() // iOS device and simulator targets; iosMain and iosTest source sets
}

Для других комбинаций целей создайте иерархию вручную, связав наборы исходного кода с отношением dependsOn.

kotlin{
    sourceSets {
        val desktopMain by creating {
            dependsOn(commonMain)
        }
        val linuxX64Main by getting {
            dependsOn(desktopMain)
        }
        val mingwX64Main by getting {
            dependsOn(desktopMain)
        }
        val macosX64Main by getting {
            dependsOn(desktopMain)
        }
    }
}

kotlin {
    sourceSets {
        desktopMain {
            dependsOn(commonMain)
        }
        linuxX64Main {
            dependsOn(desktopMain)
        }
        mingwX64Main {
            dependsOn(desktopMain)
        }
        macosX64Main {
            dependsOn(desktopMain)
        }
    }
}

Благодаря иерархической структуре проекта библиотеки также могут предоставлять общий API для подмножества целей. Узнайте больше о общем коде в библиотеках.

Использование нативных библиотек в иерархической структуре

Вы можете использовать зависящие от платформы библиотеки, такие как Foundation, UIKit и POSIX, в наборах исходного кода, общих для нескольких нативных целей. Это поможет вам использовать больше нативного кода, не ограничиваясь зависимостями, специфичными для платформы.

Дополнительные шаги не требуются — все выполняется автоматически. IntelliJ IDEA поможет вам определить общие объявления, которые вы можете использовать в общем коде.

Узнайте больше о применении библиотек, зависящих от платформы.

Указание зависимостей только один раз

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

kotlin {
    sourceSets {
        val commonMain by getting {
            dependencies {
                implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.7.1")
            }
        }
    }
}

kotlin {
    sourceSets {
        commonMain {
            dependencies {
                implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.7.1'
            }
        }
    }
}

Не используйте имена артефактов библиотек kotlinx с суффиксами, указывающими платформу, такими как -common, -native, или аналогичными, так как они больше НЕ поддерживаются. Вместо этого используйте имя базового артефакта библиотеки, которое в приведенном выше примере — kotlinx-coroutines-core.

Однако это изменение пока не затрагивает:

• Библиотеку stdlib — начиная с Kotlin 1.4.0, зависимость от стандартной библиотеки добавляется автоматически.

• Библиотеку kotlin.test — вы все еще должны использовать test-common и test-annotations-common. Эти зависимости будут рассмотрены позже.

Если вам нужна зависимость только для определенной платформы, вы по-прежнему можете использовать платформоспецифические варианты стандартных и kotlinx библиотек с такими суффиксами, как -jvm или -js, например, kotlinx-coroutines-core-jvm.

Узнайте больше о настройке зависимостей.

Зависимость от стандартной библиотеки добавляется по умолчанию

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

Автоматически добавленная стандартная библиотека будет иметь ту же версию, что и плагин Kotlin Gradle, так как они имеют одинаковую систему версионирования.

Для наборов исходных кодов, специфичных для платформы, используется соответствующая платформа-специфичная версия библиотеки, а общая стандартная библиотека добавляется ко всем остальным. Плагин Kotlin Gradle выберет соответствующую стандартную библиотеку JVM в зависимости от kotlinOptions.jvmTarget опции компилятора вашего скрипта Gradle.

Узнайте, как изменить поведение по умолчанию.

Минимальная версия Gradle для проектов Kotlin

Чтобы использовать новые функции в своих проектах Kotlin, обновите Gradle до последней версии. Многоплатформенные проекты требуют Gradle 6.0 или выше, а другие проекты Kotlin работают с Gradle 5.4 или выше.

Улучшенная поддержка *.gradle.kts в IDE

В версии 1.4.0 мы продолжили улучшение поддержки IDE для скриптов Gradle Kotlin DSL (*.gradle.kts файлы). Вот что приносит новая версия:

• Явное загрузка конфигураций скриптов для повышения производительности. Ранее внесенные изменения в скрипт сборки загружались автоматически в фоновом режиме. Для повышения производительности в версии 1.4.0 мы отключили автоматическую загрузку конфигурации скрипта сборки. Теперь IDE загружает изменения только при явном их применении.

  В версиях Gradle, предшествующих 6.0, вам необходимо вручную загрузить конфигурацию скрипта, нажав Загрузить конфигурацию в редакторе.

  

  В Gradle 6.0 и выше вы можете явно применить изменения, нажав Загрузить изменения Gradle или повторно импортировав проект Gradle.

  Мы добавили еще одно действие в IntelliJ IDEA 2020.1 с Gradle 6.0 и выше – Загрузить конфигурации скриптов, которое загружает изменения в конфигурации скриптов без обновления всего проекта. Это занимает гораздо меньше времени, чем повторный импорт всего проекта.

  

  Вам также следует Загрузить конфигурации скриптов для вновь созданных скриптов или при первом открытии проекта с новым плагином Kotlin.

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

  В настоящее время такая загрузка ограничена build.gradle.kts и settings.gradle.kts файлами (пожалуйста, проголосуйте за соответствующую задачу). Чтобы включить выделение для init.gradle.kts или примененных скрипт-плагинов, используйте старый механизм – добавьте их в автономные скрипты. Конфигурация для этих скриптов будет загружена отдельно, когда это потребуется. Вы также можете включить автоматическую перезагрузку для таких скриптов.

  

• Улучшенная обработка ошибок. Ранее вы могли видеть ошибки Gradle Daemon только в отдельных лог-файлах. Теперь Gradle Daemon возвращает всю информацию об ошибках напрямую и отображает ее в окне инструмента сборки. Это экономит ваше время и усилия.

Новый API разрешения зависимостей

В версии 1.4.0 мы представили новый API для разрешения внешних зависимостей (например, артефактов Maven), а также реализации для него. Этот API опубликован в новых артефактах kotlin-scripting-dependencies и kotlin-scripting-dependencies-maven. Предыдущая функциональность разрешения зависимостей в библиотеке kotlin-script-util теперь устарела.

Новый API REPL

Новый экспериментальный API REPL теперь является частью API Kotlin Scripting. Существует также несколько реализаций его в опубликованных артефактах, некоторые из которых обладают расширенной функциональностью, такой как автодополнение кода. Мы используем этот API в ядре Kotlin Jupyter, и теперь вы можете попробовать его в собственных пользовательских оболочках и REPL.

Кэш скомпилированных сценариев

API Kotlin Scripting теперь предоставляет возможность реализовать кэш скомпилированных сценариев, что значительно ускоряет последующие выполнения неизменённых сценариев. Наша стандартная расширенная реализация сценариев kotlin-main-kts уже имеет свой собственный кэш.

Переименование артефактов

Для избежания путаницы с именами артефактов мы переименовали kotlin-scripting-jsr223-embeddable и kotlin-scripting-jvm-host-embeddable в просто kotlin-scripting-jsr223 и kotlin-scripting-jvm-host. Эти артефакты зависят от артефакта kotlin-compiler-embeddable, который затемняет связанные сторонние библиотеки, чтобы избежать конфликтов в использовании. С этим переименованием мы делаем использование kotlin-compiler-embeddable (что, как правило, безопаснее) стандартным для сценариев-артефактов. Если по какой-то причине вам нужны артефакты, зависящие от незатемнённого kotlin-compiler, используйте версии артефактов с суффиксом -unshaded, например, kotlin-scripting-jsr223-unshaded. Обратите внимание, что это переименование затрагивает только сценарий-артефакты, которые предполагается использовать напрямую; имена других артефактов остаются неизменными.