Kotlin 1.4.0-RC リリース

Elizaveta Semakova

Read this post in other languages:

• English
,
• 한국어
,
• Русский

Kotlin の次期バージョンのリリースまでわずかとなりました！ リリース候補版 Kotlin 1.4.0-RC をご紹介します。 Kotlin 1.4.0-RC の変更内容について、以下をお読みください。また、正式にリリースされる前に、Kotlin 1.4 の新機能をぜひお試しください。

マイルストーンリリース（1.4-M1、1.4-M2、および 1.4-M3）をお試しいただいた皆さん、フィードバックをお送りいただいた皆さん、そしてこのバージョンの Kotlin の改善に力を貸していただいた皆さんに、心よりお礼申し上げます！

この記事では、Kotlin 1.4.0-RC で提供される以下の新機能と主な機能強化に焦点を当てています。

• *.gradle.kts IDE サポートの強化。スクリプト構成の明示的な読み込みとエラーレポート機能を改善しました。
• マルチプラットフォームプロジェクトと単一プラットフォームをターゲットするプロジェクトの両方で、すべてのソースセットに、標準ライブラリ依存関係がデフォルトで含まれるようになりました。
• CocoaPods 依存関係の管理を簡略化しました。
• Gradle における npm 依存関係、CSS、および dukat の Kotlin/JS 統合と、デフォルトコンパイラバックエンドでの @JsExport 注釈を使用する機能を改善しました。
• Node.js API バインディングのプレビュー。

*.gradle.kts IDE サポートの強化

Kotlin 1.3.70 では Gradle Kotlin DSL スクリプト（*.gradle.kts ファイル）の IDE サポートを大幅に改善しましたが、Kotlin 1.4.0-RC においてさらなる機能強化を図りました。 新しいバージョンでは以下の内容が改善されています。

パフォーマンス改善のためスクリプト構成の読み込みを明示的に

以前は、build.gradle.kts の buildscript または plugins ブロックに新しいプラグインを追加すると、新しいスクリプト構成はバックグラウンドで自動的に読み込まれていました。 そして、適用した後に、新たに追加されたプラグインでコーディング支援を使用することができました。

パフォーマンスを改善するために、入力時にスクリプト構成に変更を自動的に適用するこの動作を取り除くことにしました。 Gradle 6.0 以降では、 Load Gradle Changes をクリックするか Gradle プロジェクトをインポートしなおすことで、明示的に構成に変更内容を適用する必要があります。

以前のバージョンの Gradle では、エディター内で Load Configuration をクリックしてスクリプト構成を手動で読み込む必要があります。

Gradle 6.0 以降を使用する IntelliJ IDEA 2020.1 に、 Load Script Configurations というアクションをもう 1 つ追加しました。このアクションは、プロジェクト全体を更新せずに、スクリプト構成への変更を読み込みます。 そのため、プロジェクト全体をインポートし直すより短時間で変更を読み込むことができます。

エラー通知機能の改善

以前は、Gradle Daemon（バックグラウンドで実行し、すべての Gradle 関連タスクとアクティビティを管理するプロセス）のエラーは別のログファイルでのみ確認できました。 このリリースでは、Gradle 6.0 以上を使用している場合、Gradle Daemon はエラーに関する情報を直接返し、Build ツールウィンドウに表示するようになりました。 このため、時間と労力の両方を節約できます。

プロジェクト構成のボイラープレートを削減

Kotlin Gradle プラグインへの改善により、Gradle ビルドファイルに書き込むコードの量が少なくなりました。最も一般的なシナリオは、デフォルトで有効化されています。

標準ライブラリがデフォルトの依存関係に

圧倒的大半のプロジェクトにおいて、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 で発表された階層的なプロジェクト構造のサポートにより、ほかの依存関係の指定も1回限りで済みます。 そのため、Gradle ビルドファイルがより簡潔で読みやすくなります。

...

android()
ios()
js()

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

...

プラットフォームソースセットとバックエンド共有ソースセットについては、それぞれに対応する標準ライブラリが追加されますが、それ以外には、共通の標準ライブラリが追加されます。 kotlinOptions.jvmTarget の設定に応じて、Kotlin Gradle プラグインが適切な JVM 標準ライブラリを選択します。

標準ライブラリの依存関係を明示的に宣言した場合（別のバージョンが必要な場合など）、Kotlin Gradle プラグインはそれをオーバーライドせずに、2番目の標準ライブラリを追加します。 また、標準ライブラリをまったく必要としない場合は、以下のように、Gradle プロパティにオプトアウトのフラグを追加する必要があります。

 kotlin.stdlib.default.dependency=false 

Kotlin/Native

CocoaPods 依存関係の管理を単純化

以前は、プロジェクトを依存関係マネージャーの CocoaPods に統合すると、iOS、macOS、watchOS、または tvOS の部分は、マルチプラットフォームプロジェクトのほかの部分とは別となり、Xcode のみでビルドすることができました。 一方、ほかの部分は、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 プロジェクト）と、1 つ以上のターゲットを持つ 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) ファイルで、kotlin("native.cocoapods") を使って CocoaPods プラグインを適用します。

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

CocoaPods リポジトリから Pod ライブラリへの依存関係を追加する

1. pod() を使用して、CocoaPods リポジトリから使用する Pod ライブラリへの依存関係を追加します。 また、subspec として依存関係を追加することもできます。

   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 Daemon からのコンパイラの実行という2つの新機能を導入しました。 皆さんからのフィードバックのお陰で、これらの機能に生じていた多数の課題を修正し、安定性を総合的に改善することができました。そして、引き続き改善に努める意向です。
• また、ランタイムパフォーマンスへの改善も行われています。 総合的なランタイムパフォーマンスは、GC の最適化によって改善されています。 この改善は特に、長く存在するオブジェクトが多数あるプロジェクトで明確化します。 HashMap と HashSet コレクションは、冗長するボクシングをエスケープすることでより素早く機能するようになりました。

Kotlin/JS

Kotlin 1.4.0-RC では、@JsExport 注釈は、デフォルトコンパイラバックエンドに対応できるようになりました。 また、Gradle プロジェクト向けに npm 依存関係管理と Dukat 統合をより堅牢で細かく調整できるコントロールを提供し、CSS サポートの精緻化と、Node.js API との統合の導入なども行っています。

デフォルトコンパイラバックエンド向けの @JsExport 注釈

Kotlin 1.4 の前回のマイルストーンでは、@JsExport 注釈を導入しました。これは、新しい IR コンパイラバックエンドを使用する際に、JavaScript や TypeScript が提供するトップレベルの宣言を行うために使用するものです。 Kotlin 1.4-M3 からは、この注釈を現在のデフォルトコンパイラバックエンドと使用できるようにもなりました。 現在のデフォルトコンパイラバックエンドを使用する際に、@JsExport でトップレベル宣言をアノテーションすると、宣言の名前マングリングがオフになります。 両方のコンパイラバックエンドにこの注釈がある場合、トップレベル宣言をエクスポートするロジックを調整せずにコンパイラ間を移行できるようになります。

npm 依存関係管理への変更

依存関係宣言に関する明示的なバージョン要件

バージョン番号を指定せずに npm パッケージへの依存関係を宣言すると、使用するパッケージを確実に管理することが困難となります。 このため、今後は、依存関係に関する npm の semver 構文に基づいて、バージョンまたはバージョン範囲を明示的に指定する必要があります。 Gradle DSL も依存関係の複数の範囲をサポートできるようになったため、以下のようにして、プロジェクトにどのバージョンを許可するのかを明確にピンポイントできるようになりました。

dependencies {
   implementation(npm("react", "> 14.0.0 <=16.9.0"))
}

その他の npm 依存関係

dependencies ブロック内に npm(...) 使って指定する npm の通常の依存関係のほかに、使用できる依存関係の種類が 3 つ追加されました。

• devDependencies に対応する devNpm(...)
• optionalDependencies に対応するoptionalNpm(...)
• peerDependencies
  に対応する peerNpm(...)
  どの依存関係をいつ使用するのかについては、npm からリンクされている公式のドキュメントを参照してください。

推移的な npm 依存関係の自動インクルージョンと解決

作成者が手動で package.json ファイルをアーティファクトに追加していないライブラリに依存する場合、以前は npm 依存関係を手動でインポートする必要がある場合がありました。 たとえば、kotlinx.serialization の場合、パッケージが Kotlin/JS で機能できるように、Gradle ビルドファイルに依存関係として text-encoding と abort-controller を含める必要がありました。

今後は、Gradle プラグインがライブラリの package.json ファイルを自動的に生成し、jar または klib アーティファクトにそれらを含めるようになります。 この種のライブラリを含める際は、ファイルが自動的に解析されて、必要な依存関係が自動的に含められるため、Gradle ビルドファイルに手動で追加する必要がなくなります。

CSS サポートの調整

Kotlin 1.4-M2 では、cssSettings を使って Gradle から直接 webpack の CSS とスタイルローダーを使用できるようになりました。 実際のタスクと効果をより緊密に反映するために、構成パラメーターを cssSupport に名前変更しました。 今後、Gradle プラグインでは、1.4-M2 で試験的に行ったデフォルト設定による CSS サポートは有効化されなくなります。 この変更によって、スタイルシートによる処理方法（Sass または Less ローダーを使用するなど）に関する独自の設定を含めている方の混乱がなくなることを願っています。 こういった場合、プロジェクトのデフォルト構成がすでに競合を生じる可能性のある CSS 設定をインジェクトしていることはすぐにはわからないためです。

プロジェクトの CSS サポートを有効にするには、webpackTask、 runTask、および testTask に対して、Gradle ビルドファイルに cssSupport.enabled フラグを設定してください。 IntelliJ IDEA に含まれるウィザードを使用して新しいプロジェクトを作成する際は、これらの設定は生成された build.gradle(.kts) ファイル内に自動的に含まれます。

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

各タスクに対してこれらの設定を個別に調整するのは、あまり便利ではないことは認識しています。 そこで、プラグインの DSL に cssSupport を構成するための場所を 1 箇所に設けることを考えています（進捗は、こちらで確認できます）。

Dukat 統合の改善

Kotlin/JS Gradle プラグインによって、TypeScript 宣言ファイル（.d.ts）を Kotlin の外部宣言に自動的に変換する Dukat ツールとの統合をより細かく調整するための制御が追加されますが、 Dukat が宣言を生成する場合とそのタイミングは、次の 2 つの方法を使用して選択することができます。

ビルド時に外部宣言を生成する

npm の依存関係関数では、パッケージ名とバージョンの後に generateExternals という 3 つ目のパラメーターを使用できるようになりました。 このため、次のようにして、Dukat が特定の依存関係に対して宣言を生成するかどうかを制御することができます。

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

gradle.properties ファイルに kotlin.js.generate.externals フラグ（experimental段階では kotlin.js.experimental.generateKotlinExternals と名付けられていたもの）を使用して、すべての npm 依存関係に関するジェネレータの振る舞いを同時に設定することができます。 通常通り、個別の明示的な設定は、この汎用フラグより優先されます。

Gradle タスクを介して手動で外部宣言を生成する

Dukat が生成する宣言を完全に制御する場合、調整を手動で適用する場合、または自動生成された外部宣言に問題が生じている場合は、generateExternals という Gradle タスクを使用して、すべての npm 依存関係に対する宣言の作成を手動でトリガすることもできます。 これにより、プロジェクトルートの externals というディレクトリに宣言が生成されます。 この時点で、生成されたコードを確認し、ソースディレクトリに使用する部分をコピーすることができます。 （ソースフォルダに外部宣言の手動での提供と、同じ依存関係に対する外部宣言をビルド時に生成できるようにすると、名前解決の問題が生じる可能性があることに注意してください。）

kotlin.dom と kotlin.browser を個別のアーティファクトに移行

Kotlin/JS のブラウザと DOM バインディングの進化を加速し、言語そのもののリリースサイクルから分離するために、kotlin.dom と kotlin.browser パッケージにある現在の API を廃止することになりました。 これらの API に代わるものは、kotlinx.dom と kotlinx.browser パッケージに提供されますが、今後のリリースで個別のアーティファクトに抽出される予定です。 これらの新しい API への移行は単純です。 プロジェクトに使用されている import を、新しい kotlinx パッケージポイントするように調整してください。

プレビュー: kotlinx-nodejs

Node.js API の公式バインディング kotlinx-nodejs のプレビューを紹介します。 Kotlin で Node.js をターゲットとすることはずっと前から可能だったことですが、その API へのタイプセーフアクセスが提供されることにより、ターゲットへの全能力が解放されます。 kotlinx-nodejs バインディングについては、GitHub を確認してください。

プロジェクトに kotlinx-nodejs を追加するには、リポジトリに jcenter() が追加されていることを確認してください。 その後で、そのアーティファクトへの依存関係を追加することができます。

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

Gradle の変更を読み込むと、DNS 解決パッケージを使用するなどして、Node.js が提供する API を試すことができます。

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.js Gradle プラグインに代わり、正式に使用廃止となります。 これらプラグインに提供されていた主な機能は、kotlin-frontend-plugin（すでに使用廃止）とともに新しいプラグインに凝縮されており、Kotlin/マルチプラットフォームプロジェクトとも互換性のある統一された DSL を使用して、Kotlin/JS ターゲットを構成することができます。

Kotlin 1.3.70 より、browserProductionRun と browserProductionWebpack タスクを使用する際に自動的にデッドコード削除（DCE）が適用されるようになっています。この機能の実行により、プログラムに最適なバンドルが作成されます。 （デッドコード削除は現在、Node.js またはテストではなく、本番出力のブラウザをターゲットする際にのみ利用できることに注意してください。 ただし、ほかに解決を希望するユースケースがある場合は、お気軽に JetBrains にご連絡ください。）

作業の効率性に関するその他の改善と注目すべき修正点

• @JsExport 注釈の禁止された使用方法に対し、そのような問題をハイライトするためにコンパイラエラーを追加しました。
• IR コンパイラバックエンドを使用する場合に、klib のインクリメンタルコンパイルを含める新しい戦略を有効化しました。コンパイル時間を改善するために講じている多くのステップの 1 つです。
• webpack 開発サーバーの構成が調整され、ホットリロード機能を使用する際の ENOENT: no such file or directory といったエラーを回避できるようになりました。

Kotlin 標準ライブラリ API の進化

Kotlin 1.4 は、Kotlin の進化の観点からは機能リリースとして捉えられており、以前のブログ記事ですでに紹介した多数の新機能が含まれています。 しかし、機能リリースには、既存の API に大々的な変更が含まれるという重要な側面もあります。 1.4 リリースに導入予定の変更について、以下に簡単にまとめています。

experimental API の stable 化

Kotlin ライブラリに求められている新しい特徴をできるだけ早く紹介するために、 experimental なバージョンを提供しています。 このステータスは、API への作業は進行中の状態にあり、互換性を考慮されることなく将来的に変更される可能性があることを示しています。 experimental な API を使用する場合、コンパイラからそのステータスに関する警告が発せられ、オプトインが要求されます（@OptIn 注釈）。

機能リリースでは、experimental API が stable な機能に昇格されることがあります。 この時点で、その形態と振る舞いが突如変更されることがないことが保証されます（変更は、適切な使用廃止サイクルでのみ可能です）。 API が正式に stable 化されると、警告やオプトインを必要とすることなく API を安全に利用できるようになります。

1.4 では、Kotlin ライブラリの多数の experimental 関数が stable 化されます。 以下はその一部を示すもので、導入されたバージョンとともに記載しています。

• 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: コレクション操作 randomOrNull() / reduceOrNull() / scan()、MutableList の remove*() 関数、ArrayDeque クラス
• 1.4-M2: コレクション操作 onEachIndexed() と reduceIndexedOrNull()、runningFold() と runningReduce()

1.4 ではその他の API 関数とクラスも stable 化されます。 このバージョン（1.4.0-RC）より、それらをプロジェクトで使用する際に、@OptIn 注釈を使用する必要はありません。

使用廃止（Deprication）サイクル

機能リリースでは、既存の使用廃止サイクルも次の段階へと移行されます。 インクリメンタルリリースでは、WARNING（警告）レベルで新しい使用廃止サイクルが開始されるだけですが、機能リリースでは、それらが ERROR（エラー）レベルへと使用規制が強化されます。 これにより、すでに ERROR レベルにある API 要素は、コードで新たに使用できないように非表示となり、コンパイル済みのコードでの互換性を維持するためだけにバイナリーの形態で残されることになります。 ともに、こういったステップによって使用廃止 API 要素の削除が段階的に行われるようになっています。

使用廃止レベルが WARNING となっている API 要素がコードに使用されている場合は、コンパイラによってその使用状況が警告されます。 Kotlin 1.4.0-RC に更新すると、これらの警告の一部はエラーに変わります。 IDE のプロンプトを利用して、エラーとされる使用箇所を代替として指定される方法に正しく変更し、コードを必ずコンパイルし直してください。

Kotlin 標準ライブラリ API への重大な変更に関する詳しい情報については、「Kotlin 1.4 の互換性ガイド」を参照してください。

スクリプト作成

前のブログ投稿ではこのセクションを省略しましたが、1.4 での Kotliln スクリプトの安定化、高速化、使いやすさへの改善をやめたわけではありません。 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 に依存するアーティファクトが必要な場合は、kotlin-scripting-jsr223-unshaded というように、-unshaded サフィックスを使ったアーティファクトバージョンを使用してください。 この名前変更の効果は、直接使用されるスクリプティングアーティファクトにのみ影響します。ほかのアーティファクトの名前に変更はありません。

使用廃止となった CLion IDE プラグイン

CLion IDE プラグインの使用廃止サイクルを開始しました。 もともと、Kotlin/Native 実行可能ファイルのデバッグに使用することを目的としていたものですが、 この機能は現在 IntelliJ IDEA Ultimate で提供されています。 そのため、1.4 リリースからは CLion IDE プラグインの公開を停止することにしました。 この使用廃止によってなんらかの問題が生じる場合は、JetBrains にご連絡ください。 問題を解決できるように、努めさせていただきます。

互換性

すべてのメジャーリリースと同様に、Kotlin 1.4 を以て、以前に発表した変更の使用廃止サイクルが一部終了を迎えます。 すべてのケースは言語委員会による十分な検討の後、「Kotlin 1.4 の互換性ガイド」に記載されています。 また、YouTrack でも変更内容を確認することができます。

リリース候補ノート

Kotlin 1.4 の最終リリース候補にようやくたどり着きました。ここからは、皆さんがコンパイルと公開を行う番です！ 前回のマイルストーンリリースとは異なり、Kotlin 1.4.0-RC で作成されたバイナリーは、Kotlin 1.4.0 との互換性が保証されています。

新機能を試すには

いつものように、play.kotl.inでKotlinをオンラインで試すことができます。

IntelliJ IDEA と Android Studio 内で、Kotlin プラグインをバージョン1.4.0-RC に更新できます。 その方法についてはこちらを参照してください。

プレリリースバージョンをインストールする前に作成された既存のプロジェクトを使用する場合、GradleまたはMavenでプレビューバージョン用にビルドを構成する必要があります。 以前のプレビューバージョンとは異なり、Kotlin 1.4.0-RC は Maven Central からも直接提供されています。 つまり、ビルドファイルに手動で kotlin-eap リポジトリを追加する必要はありません。

コマンドラインコンパイラは、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 チャンネルにご参加ください（招待状はこちらから入手できます）。 このチャンネルでは、質問やディスカッションへの参加を行い、新しいプレビュービルドに関する通知を受信することができます。

Kotlinを使ってみよう!

ご協力いただいた外部貢献者

このリリースに含められた Pull リクエストは、次の外部貢献者からいただきました。ご協力いただきありがとうございました。

• 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

Subscribe to Kotlin Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!