Что нового в Kotlin 1.4

Преобразования 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)}")
}

Узнайте больше об интерфейсах Kotlin и преобразованиях SAM.

Явный режим 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).

Это было действительно раздражающим, когда все аргументы были в правильном порядке, но вы хотели указать имя для одного аргумента посередине. Это особенно полезно для явного указания, к какому атрибуту относится булево или 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's default методы. Для этой цели существовал механизм, который включает аннотацию @JvmDefault для маркировки таких методов и параметр компилятора -Xjvm-default для включения обработки этой аннотации.

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

Обратите внимание, что с точки зрения разработчика, изменения будут незначительны: код 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 разработки, peer и optional с использованием devNpm, optionalNpm и peerNpm. Подробнее о управлении зависимостями пакетов npm непосредственно из Gradle можно узнать здесь.

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

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

Бэкенд IR для Kotlin/JS, который в настоящее время имеет стабильность Alpha, предоставляет новые функции, специфичные для цели 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 мы немного изменили API Swift, сгенерированный из 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. Новая зависимость будет добавлена автоматически. Дополнительные шаги не требуются.

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

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

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

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

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

Например, в типичном проекте multiplatform, нацеленном на 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.6.0")
            }
        }
    }
}

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

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