Kotlin 1.4.0-RC！

觸手可及！我們很高興地宣佈Kotlin 1.4.0-RC，它將是我們的程式語言下一個主要版本的候選，請繼續閱讀以瞭解Kotlin 1.4.0中的變化，並確保在Kotlin 1.4.0正式釋出前嘗試了這些新特性。

特別感謝所有嘗試過(1.4-M1, 1.4-M2, 和1.4-M3)里程碑版本，並分享了反饋，有助於我們對該Kotlin版本改進的使用者。

這篇部落格著重介紹Kotlin 1.4.0-RC中可用的新特性及關鍵改進：

• 顯式載入指令碼配置及更好體驗的錯誤報告，顯著提升在IDE使用*.gradle.kts的體驗。
• 現在所有源集都預設包含了標準庫的依賴，適用於多平臺及單個平臺專案。
• 簡化了對CocoaPods依賴項的管理。
• 改進了在Grdle中Kotlin/JS對npm依賴、css和dukat的整合，以及可在編譯後端使用@JsExport註解的功能了。
• Node.js API bindings的預覽。
• 用於除錯協程及定義深度遞迴函式的新功能。這些主題在單獨的部落格中討論。

提升IDE對*.gradle.kts的支援

我們在Kotlin 1.3.70中顯著改善了IDE對Gradle Kotlin DSL指令碼（* .gradle.kts檔案的支援，改進在Kotlin 1.4.0-RC中仍在持續。以下新版本帶來的功能：

顯式載入指令碼配置效能更加優異

在之前，當你向build.gradle.kts的buildscript或plugins塊新增外掛後，新的指令碼配置將在後臺自動載入。在指令碼被應用後，你將能使用新外掛的程式碼提示功能。

在Gradle的早期版本中，你需要在編輯器中手動點選Load Configuration載入指令碼配置。

我們在Gradle 6.0+的IntelliJ IDEA 2020.1中增加了另一個action， Load Script Configurations，只載入了指令碼配置的變動，而非更新整個專案。這比重新匯入整個專案所需的時間少得多。

更好的錯誤報告

以前只能在獨立的日誌檔案中看到Gradle Daemon(後臺執行的程式，該程式負責所有與Gradle相關的任務和活動)的報錯。現在，如果你用Gradle 6.0及更高的版本，則Gradle守護程式將直接返回有關錯誤的所有資訊，並將其顯示在Build工具視窗中。這樣省時又省力。

專案配置中更少的樣板程式碼

透過改進Kotlin Gradle外掛，你可以在Gradle build檔案中編寫更少的程式碼：預設啟用了最通用的方案。

標準庫成為了預設依賴

絕大多數專案都需要依賴Kotlin標準庫。從1.4.0-RC開始，不再需要在每個源集中手動加入stdlib的依賴-現在會預設新增。自動新增的標準庫版本取決於所使用Kotlin Gradle外掛，因為它們版本相同。

這是1.4前Android，iOS和JavaScript目標的多平臺專案配置示例：

...

android()
ios()
js()

sourceSets {
    commonMain {
        dependencies {
            implementation("org.jetbrains.kotlin:kotlin-stdlib-common")
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core-common:1.3.6")
        }
    }
   
    androidMain {
        dependencies {
            implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8")
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.6")
        }
    }

    jsMain {
        dependencies {
            implementation("org.jetbrains.kotlin:kotlin-stdlib-js")
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core-js:1.3.6")
        }
    }

    iosMain {
        dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core-native:1.3.6")
        }
    }
}

...

現在，你完全不需要顯式宣告對標準庫的依賴，並且支援在1.4-M2中公佈的分層架構專案了，你只需宣告一次依賴項。因此Gradle build檔案將更加簡潔和易讀：

...

android()
ios()
js()

sourceSets {
    commonMain {
        dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.6")
        }
    }
}

...

對於平臺及後端共享的程式碼源集，會新增相應的標準庫，而餘下部分將新增通用的標準庫。Kotlin Gradle外掛將根據kotlinOptions.jvmTarget配置選擇恰當的JVM標準庫。

如果你明確指定了標準庫依賴(例如需要其他版本)，Kotlin Gradle外掛則不會覆蓋或增加第二個標準庫。而如果你根本不需要標準庫，則可以向Gradle配置新增opt-out標記：

kotlin.stdlib.default.dependency=false

Kotlin/Native

簡化CocoaPods的依賴管理

之前，一旦你在專案中整合了依賴管理器CocoaPods，便可以只在Xcode中構建多平臺專案中的iOS，macOS，watchOS，或tvOS部分。而其餘部分則可在IntelliJ IDEA進行構建。

此外，每當向儲存在CocoaPods(Pod庫)的Objective-C庫新增依賴時，都必須從IntelliJ IDEA切換到Xcode，執行pod install任務及Xcode的構建。

而現在你既可以在IntelliJ IDEA中管理Pod依賴，同時享受它為編碼工作帶來的便利了，例如程式碼高亮及補全。同樣你也無需切換到Xcode便能透過Gradle構建整個Kotlin專案。這意味著，只有在你需要編寫Swift/Objective-C程式碼或將應用執行到模擬器及裝置上時，才需要切換到Xcode了。

現在你也能在本地儲存的Pod庫上工作了。

根據需求，你可以新增以下之一依賴：

• Kotlin專案和CocoaPods儲存庫中的Pod庫。
• Kotlin專案和本地儲存的Pod庫。
• Kotlin Pod(用作CocoaPods依賴項的Kotlin專案)和具有一或多個目標的Xcode專案。

完成初始化配置，然後向CocoaPods新增新依賴項時，只需在IntelliJ IDEA中重新匯入專案即可。無需其他步驟，新的依賴項將會自動新增。

下面說明有關如何向CocoaPods儲存庫中新增對Pod庫的依賴。 Kotlin 1.4的文件將涵蓋所有場景。

如何使用CocoaPods整合器

安裝CocoaPods依賴管理及其外掛

1. 安裝cocoapods依賴管理器(sudo gem install cocoapods)
2. 安裝cocoapods-generate外掛 (sudo gem install cocoapods-generate).
3. 在專案的build.gradle(.kts)檔案中，CocoaPods外掛需搭配kotlin("native.cocoapods"):

plugins {
   kotlin("multiplatform") version "1.4.0-rc"
   kotlin("native.cocoapods") version "1.4.0-rc"
}

從CocoaPods倉庫中新增對Pod庫的依賴

1. 在CocoaPods儲存庫中透過pod()新增要使用的Pod庫依賴。 你還可以將依賴以子模組方式新增。

kotlin {
    ios()

    cocoapods {
        summary = "CocoaPods test library"
        homepage = "https://github.com/JetBrains/kotlin"
        pod("AFNetworking", "~> 4.0.0")

        //Remote Pod added as a subspec
        pod("SDWebImage/MapKit")
    }
}

2. 重新匯入專案。 要在Kotlin能訪問依賴，請匯入以下包：

import cocoapods.AFNetworking.*
import cocoapods.SDWebImage.*

我們也很樂意向你共享一個示例專案，示例演示瞭如何向CocoaPods遠端倉庫及本地的Pod庫新增依賴。

預設在Apple目標上生成正式的.dSYM

iOS應用程式除錯崩潰時會需要分析崩潰報告，而崩潰報告通常需要符號對映才能正常閱讀。要在Kotlin中進行地址對映，需要Kotlin程式碼的.dSYM包。從1.4-M3開始，Kotlin/Native編譯器會預設在Darwin平臺上為發行版二進位制檔案生成.dSYM。它可以被-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開發流程的整體效能：

• 在1.3.70中，我們引入了兩個新特性來提高Kotlin/Native的編譯效能：專案依賴快取和執行在Gradle守護程式的編譯器。同時感謝你的反饋，讓我們設法解決了許多問題並提高了這些功能的整體穩定性，我們會繼續努力。
• 執行時效能也得到了一些改進。由於GC的最佳化，整體執行時效能得到了提高。改進在有大量長生命週期物件的專案中尤其明顯。 HashMap和HashSet集合現在會透過避免多餘的裝箱來提高效能。

Kotlin/JS

在Kotlin 1.4.0-RC中，我們讓預設的編譯器後端相容@ JsExport註解。除此之外，我們還為npm依賴管理和整合Dukat的Gradle專案提供更健壯和更細粒度的控制，進一步完善了對CSS的支援，並首次展示Node.js API的整合。

預設編譯器後端的@JsExport註解

在之前Kotlin 1.4的里程碑版本中，我們引入了@JsExport註解，在使用新的IR編譯器後端時，該註解用於從JavaScript或TypeScript中提供頂層宣告。Kotlin 1.4-M3開始，已允許在當前預設的編譯器後端中使用該註解了。若配合當前預設的編譯器後端時，@JsExport註釋的頂層宣告將被禁止名字調整。兩個編譯器後端都具有該註解，使得你可以在其中隨意切換，而不必調整頂層宣告的匯出邏輯。請注意，僅在使用新的IR編譯器後端時，才可以使用TypeScript定義。

npm依賴管理的變動

依賴要求顯式指定版本

在不指定版本號的情況下宣告npm包依賴會讓其管理變得困難。這就是為什麼從現在開始，需要根據npm的semver語法明確指定版本或版本範圍的原因。 Gradle DSL還支援多個範圍的依賴，從而可以精準確定專案所接受的版本，例如：

NPM依賴的其他依賴型別

除了你在dependencies塊中使用npm(...)指定的常規依賴外，現在還可以使用三種依賴：

• 使用devNpm(...)的devDependencies
• 使用optionalNpm(...)的optionalDependencies
• 使用peerNpm(...)的peerDependencies

要了解何時該使用何種依賴型別，請查閱npm連結的官方文件。

Automatic inclusion and resolution of transitive npm dependencies

以前，如果你所依賴庫的作者沒有將package.json檔案手動新增到工件中，則有時需要手動匯入其npm依賴項。例如kotlinx.serialization就是這種情況，它要求在Gradle build檔案中包含text-encoding和abort-controller依賴，以使該軟體包在Kotlin/JS上可以使用。

現在，Gradle外掛會自動為庫生成package.json檔案，並將其包含在jar或klib構件中。當包含該種類庫時，將會自動分析檔案並引入必要的依賴項，從而無需手動將其新增到Gradle build檔案中。

CSS支援的調整

在Kotlin 1.4-M2，我們直接透過cssSettings從Gradle引入了對webpack CSS和樣式載入器的支援。為了更準確地表現其實際功能和效果，此後我們將配置引數重新命名為cssSupport。未來Gradle外掛將預設不再啟用CSS支援——我們在1.4-M2中嘗試過的設定。我們希望這個變動能避免對那些自行處理樣式表的方式造成混淆(例如使用Sass或Less載入器)。在這種情況下，專案的預設配置已經注入了一些CSS設定，這可能會導致衝突，但並不是馬上可見的。

要在你的專案中啟用CSS支援，請將Gradle build檔案的cssSupport.enabled設定到webpackTask，runTask和testTask中。使用IntelliJ IDEA中的嚮導建立新專案時，這些設定將自動包含在生成的build.gradle(.kts)檔案中：

webpackTask {
   cssSupport.enabled = true
}
runTask {
   cssSupport.enabled = true
}
testTask {
   useKarma {
      // . . .
      webpackConfig.cssSupport.enabled = true
   }
}

我們意識到每個任務都需要單獨設定很不方便。我們考慮在外掛的DSL中新增cssSupport的中心配置處(你可以在這裡瞭解我們的進度)。

Dukat整合的改進

Kotlin/JS Gradle外掛為其與Dukat的整合新增了更多細粒度的控制元件，該工具可將TypeScript宣告檔案(.d.ts)自動轉換為Kotlin的外部宣告。現在，你有兩種不同的方案來選擇是否以及何時生成Dukat：

構建時生成外部宣告

npm依賴函式在包名稱和版本之後新增了第三個引數：generateExternals。這讓你能單獨控制Dukat是否該為特定依賴項生成宣告，如下所示：

dependencies {
  implementation(npm("decamelize", "4.0.0", generateExternals = true))
}

你可以在gradle.properties檔案中透過kotlin.js.generate.externals配置(舊版本名為kotlin.js.experimental.generateKotlinExternals，當時它仍處於實驗狀態)，同時為所有npm依賴項設定生成器的行為。像往常一樣，獨立的顯式設定優先於通用配置。

透過Gradle任務手動生成外部宣告

如果要完全控制Dukat生成的宣告，應用手動配置，或者自動生成的外部物件遇到問題，還可以透過generateExternalsGradle任務手動為所有npm依賴生成宣告。將在專案根目錄名為externals的目錄生成宣告檔案。你可以檢視生成的程式碼，並將想要的部分複製到源目錄中。(請注意，在原始檔夾中手動提供外部宣告，併為同一依賴啟用構建時外部宣告生成會引發問題。(原文：”result in resolution issues”))

kotlin.dom和kotlin.browser工件分離的遷移預備

為了Kotlin/JS的browser和DOM bindings的快速發展，並讓它們與語言本身的釋出週期脫鉤，我們不贊成使用當前kotlin.dom和kotlin.browser包中的API。我們在kotlinx.dom和kotlinx.browser包提供了這些API的替代品，這些包將在未來版本中提取出來以分離工件。遷移到這些新的API很簡單。只需將專案中的匯入指向到新的kotlinx軟體包。可透過IntelliJ IDEA的Alt-Enter訪問快速修復以輔助遷移。

預覽：kotlinx-nodejs

我們很高興地分享Node.js API–kotlinx-nodejs的正式bindings的預覽。雖然一直以來都可以使用Kotlin來定位Node.js，但是當你可以透過型別安全的方式訪問其API時，就可以充分釋放該目標的全部潛能。可以在GitHub上檢視kotlinx-nodejsbindings。

要將kotlinx-nodejs新增到你的專案，請確保將jcenter()已新增到倉庫中。然後便可以輕鬆地在工件上新增依賴：

dependencies {
    // . . .
    implementation("org.jetbrains.kotlinx:kotlinx-nodejs:0.0.4")
}

Gradle的變更被載入後，你可以使用Node.js提供的API進行試驗，例如透過使用其DNS解析程式包：

fun main() {
    dns.lookup("example.org") { err, address, family ->
        console.log("address: $address, family IPv$family")
    }
}

尤其因為它是預覽版，我們建議你嘗試一下kotlinx-nodejs並向問題跟蹤器報告在倉庫遇到的任何問題。

棄用kotlin2js和kotlin-dce-js Gradle外掛

從Kotlin 1.4開始，Kotlin面向JavaScript的舊Gradle外掛將被正式棄用(kotlin2js和kotlin-dce-js)，取而代之的是kotlin.jsGradle外掛。 這些外掛中的關鍵功能以及kotlin-frontend-plugin(早前已被棄用)已被提煉到新外掛中，從而允許相容Kotlin/Multiplatform專案，使用統一的DSL配置Kotlin/JS目標。

自Kotlin 1.3.70起，當執行browserProductionRun和browserProductionWebpack任務時，無效程式碼消除(DCE)會自動應用，建立並最佳化程式的捆綁包。 (請注意，當前只有在面向瀏覽器並輸出為生產，而非Node.js或測試的情況下才可使用無效程式碼消除功能。但如果你有其他用例也需要去解決，請隨時在YouTrack上)我們分享。

其他使用者體驗改善和重要修復

• 我們為禁止使用@ JsExport註解新增了更多的編譯器錯誤，以凸顯此類問題。
• 使用IR編譯器後端時，我們啟用了一項新策略，其中包括對klib進行增量編譯，這是我們為縮短編譯時間而採取的許多步驟之一。
• webpack伺服器開發的配置已經得到調整，以防止使用熱過載功能時出現類似ENOENT：無此類檔案或目錄之類的錯誤。

不斷髮展的Kotlin標準庫API

就Kotlin的發展階段而言，Kotlin 1.4是一個功能釋出版，因此它帶來了很多你已從以前的部落格中瞭解的新功能。但是，功能釋出的另一個重要方面是它包括對現有API的重大改進。下面簡要概述1.4版本可能帶來的變化。

實驗性API趨於穩定

為了儘快交付你希望能在Kotlin庫中看到的新內容，我們提供了實驗版本。這個狀態表明API的功能仍在開發中，未來可能會有無法相容的變動。當你使用實驗性API時，編譯器會根據API的狀態向你發出警告，並要求opt-in(@ OptIn註解)。

在功能釋出版中，實驗性API會提升為穩定版本。在這一點上，我們保證其形式和行為不會突然發生變化(只在合適的棄用週期內才會變動)。一旦API穩定釋出，你就可以安全使用API，不會有警告或opt-ins了。

在1.4，我們將Kotlin庫中的許多實驗功能提升到穩定版。以下是部分示例以及它們引入的版本：

• 1.3.40: CharArray/ByteArray和String互相轉換的函式
  • ByteArray.decodeToString和String.encodeToByteArray
  • CharArray.concatToString和String.toCharArray
• 1.3.50: 位操作 countOneBits(), countLeadingZeroBits(), countTrailingZeroBits(), takeHighestOneBit(), takeLowestOneBit()
• 1.3.70: 集合操作 MutableList; ArrayDeque類的函式randomOrNull(), reduceOrNull(), scan(); remove*()
• 1.4-M2: collection operations onEachIndexed()和reduceIndexedOrNull(), runningFold()和runningReduce()

更多的API函式和類在1.4穩定。從這個版本(1.4.0-RC)開始，在專案中使用它們將不需要@OptIn註解。

棄用週期

功能釋出版還涉及當前棄用週期中採取的下一步措施。在增量版本中，我們以WARNING級別開始的新棄用週期，在功能版本中，我們將其收緊到ERROR。同樣，已是ERROR級別的API將在新的程式碼中完全隱藏，僅保留其二進位制形式，以保持與已編譯程式碼的相容性。這些流程一同確保棄用的API會逐步被移除。

如果你程式碼所使用的API棄用等級為WARNING，則編譯器會針對該用法發出警告。當你更新到Kotlin 1.4.0-RC，則其中一些警告將變成錯誤。使用IDE提示的正確用法替換錯誤的用法，並確保你的程式碼已再次編譯。

有關Kotlin標準庫API中重大更改的詳細資訊，請參見Kotlin 1.4相容性指南。

指令碼

我們在之前幾篇部落格中都跳過了本節，但是我們並沒有停止致力於Kotlin指令碼的工作，以使其在1.4中更穩定，更快，更容易使用。在RC版本中，更好的效能，大量的問題修復及功能改善，都是肉眼可見的。

工件重新命名

為了避免工件名稱混淆，我們將kotlin-scripting-jsr223-embeddable和kotlin-scripting-jvm-host-embeddable重新命名為kotlin-scripting-jsr223和kotlin-scripting-jvm-host(去掉-embeddable)。這些工件依賴於kotlin-compiler-embeddable工件，該工件將捆綁的第三方庫隱藏起來以避免使用上的衝突。透過這種重新命名，我們將kotlin-compiler-embeddable(通常更安全)作為指令碼工件的預設設定。 如果出於某種原因，你仍需要依賴於未隱藏的kotlin-compiler的工件，請使用帶有-unshaded字尾的工件版本，例如kotlin-scripting-jsr223-unshaded。請注意，這種重新命名僅影響需要直接使用的指令碼工件。其他工件的名稱保持不變。

CLion IDE外掛已經棄用

我們已經為CLion IDE外掛啟動了棄用週期。最初它用於除錯Kotlin/Native可執行檔案。現在該功能已在IntelliJ IDEA Ultimate中可用。 1.4版後，我們將停止CLion IDE外掛的釋出。如果該棄用導致任何問題，請與我們聯絡。我們將盡力幫助你解決問題。

相容性

與所有主要發行版一樣，之前宣佈的部分變更的棄用週期將在Kotlin 1.4中結束。語言委員會仔細審查了所有這些情況，並已在Kotlin 1.4相容性指南中列出。你也可以在[YouTrack]((https://youtrack.jetbrains.com/issues/KT?q=Tag: language-committee-approved Target versions: 1.4-RC, 1.4-M3, 1.4-M2, 1.4-M1, 1.4.0)檢視。

候選發行版備註

現在我們已到達了Kotlin 1.4的最終釋出候選版本了，是時候開始編譯和釋出！與之前的里程碑版本不同，可以保證Kotlin 1.4.0-RC建立的二進位制檔案能與Kotlin 1.4.0相容。

如何嘗試最新版本

同樣的，你可以在play.kotl.in線上使用Kotlin。

在IntelliJ IDEA和Android Studio，你可以更新Kotlin外掛到1.4-M2版本。操作指南。

如果要在現有專案使用預覽版，則需要在Gradle或Maven中為預覽版本配置構建。

你可以在Github發行頁下載命令列編譯器。

你可以使用隨版本發行的庫的以下版本：

• kotlinx.atomicfu版本：0.14.3-1.4.0-rc
• kotlinx.coroutines版本：1.3.8-1.4.0-rc
• kotlinx.serialization版本：1.0-M1-1.4.0-rc
• ktor版本：1.3.2-1.4.0-rc

在這裡檢視有關發行版的更多細節和相容庫列表。

分享你的反饋

如果你發現錯誤並向我們的問題跟蹤器進行報告，我們表示非常感謝。我們嘗試在最終發行版前解決所有重要問題，這意味著無需等到下一個Kotlin發行版你的問題便能得到解決。

如果你有任何疑問並想參與討論，歡迎加入Kotlin Slack(在這裡獲得邀請)的#eap channel頻道。在該頻道中，你還可以獲取有關新預覽版的通知。

Let’s Kotlin!

其他貢獻者

同樣感謝提交的PR合併到該版本中的所有其他貢獻者：

• Toshiaki Kameyama
• Steven Schäfer
• Jinseong Jeon
• pyos
• Mark Punzalan
• rapturemain
• Vitaly
• Mads Ager
• Subroh Nishikori
• Juan Chen
• gcx11
• rbares
• Henrik Tunedal
• Efeturi Money
• Yuku Kotani
• Dmitry Borodin
• Mikhail Likholetov
• Mike Samuel
• Matthew Gharrity
• Jim Sproch
• Raluca Sauciuc
• Martin Petrov
• Segun Famisa
• Sinan Kozak
• Kristoffer Andersen
• Anastasiya Krasnoryadtseva
• Vadim Semenov
• Kevin Most
• Valeriy Vyrva
• Victor Turansky