Android N Java 8機能（Jackコンパイラー）およびKotlin相互運用機能

アップデート 3。KOTLINは現在、 Androidの開発で公式にサポートされています。Googleによる。やぁぁぁぁぁぁぁぁぁす！

アップデート2：JetBrainsは長期的にはKotlin for Androidのサポートに本当に取り組んでいるようです。私は幸せなkotlinユーザーです:)。

更新：JetBrainsのHadi Haririは、このトピックに関する情報をリリースする予定であると述べました。更新があり次第、この投稿を更新します。

===次のスタッフの廃止===

Googleは、いくつかの興味深い機能を備えたAndroid Nのプレビューをリリースしました。最も顕著なのは、Java 8言語の部分的なサポートです。これは、Googleが取り組んでいる新しいJackツールチェーンのために可能です。

javacまたはkotlincを使用する現在のツールチェーン：
javac（.java-> .class）-> dx（.class-> .dex）
kotlinc（.kt-> .class）-> dx（.class-> .dex）

新しいジャックツールチェーン：
ジャック（.java-> .jack-> .dex）

私は、GoogleがJackをAndroid開発のデフォルトのツールチェーンにすることを推進すると想定しています。更新：Jackは非推奨になりました。ヤス。

私の質問は、この新しいツールチェーンが、将来、Android開発のkotlinユーザーとしてどのように影響するかということです。「過去に行き詰まった」のでしょうか？

免責事項：私はジャックに取り組んでいます

これは影響しません。KotlinのコンパイラはJava 6バイトコードを生成しますが、Jack / Jillはそれをうまくインポートできます。

@Pavel Dudka

ジャック-コンパイラです。javacに似ていますが、処理が少し異なります。

ご覧のとおり、JackはJavaソースコードを直接Dexファイルにコンパイルします。中間の* .classファイルがないため、dxツールは必要ありません。

ちょっと待って！プロジェクトにサードパーティのライブラリ（.classファイルのコレクションとして提供される）を含めるとどうなりますか？

そして、ジルが出場する時です：

Jillはクラスファイルを処理し、Jackコンパイラの入力として使用できる特別なJayce形式に変換できます。

それでは、少し脇に置いて考えてみましょう...中毒になったクールなプラグインはすべてどうなりますか？それらはすべて.classファイルを必要とし、Jackコンパイラーにはもうありません...

幸いなことに、ジャックは私たちにとって重要な機能のいくつかをすぐに利用できるように提供します。

• Retrolambda-必要ありません。ジャックはラムダを適切に処理できます
• Proguard-ジャックに組み込まれているため、難読化と最小化を引き続き使用できます

利点：

JackはJavaプログラミング言語1.7をサポートし、以下に説明する追加機能を統合します。

• プレデキシング

  JACKライ​​ブラリファイルを生成すると、ライブラリの.dexが生成され、.jackライブラリファイル内にpre-dexとして格納されます。コンパイル時に、JACKは各ライブラリのpre-dexを再利用します。すべてのライブラリは事前に指定されています。

• インクリメンタルコンパイル

  増分コンパイルとは、最後のコンパイル以降に変更されたコンポーネントとその依存関係のみが再コンパイルされることを意味します。インクリメンタルコンパイルは、変更がコンポーネントの限られたセットのみに制限されている場合、フルコンパイルよりも大幅に高速化できます。

• 再梱包

  JACKはjarjar構成ファイルを使用して再パッケージを行います。

• Multidexサポート

  dexファイルは65Kメソッドに制限されているため、65Kを超えるメソッドを持つアプリは複数のdexファイルに分割する必要があります。（multidexの詳細については、「65Kを超える方法でアプリを構築する」を参照してください。）

短所：

• 変換APIはジャックではサポートされていません-変更できる中間Javaバイトコードがないため、ここで言及しなかった一部のプラグインは機能しなくなります
• 注釈処理は現在Jackではサポートされていないため、DaggerやAutoValueなどのライブラリに大きく依存している場合は、Jackに切り替える前によく考える必要があります。編集：Jake Whartonが指摘したように、Jack in N Previewは注釈処理をサポートしていますが、Gradleからはまだ公開されていません。
• Javaバイトコードレベルで動作するLint検出器はサポートされていません。
• Jacocoはサポートされていません-まあ、私は個人的にJacocoに疑問がある（それは本当にあなたが見たいものを示していない）ので、それなしで完全に生きることができます
• Dexguard-エンタープライズバージョンのProguardは現在サポートされていません

Googleはデフォルトのツールとしてジャックをプッシュしませんが、Jack and Jill。
Jillを使用して.classファイルをdexにコンパイルする作業はこれからです。そうでなければ、jar / aarライブラリに別れを告げることができます。

ジャックまたはジルが遅くなるかどうかはまだ議論の余地があります。Androidチームは、jackが現在のビルドプロセスよりも速くなることを望んでいますが、現在はそうではありません。

さらに、JackとDexはオープンで使用できます。kotlinチームがkotlinソースコードから.jackまたは.dexファイルを出力するツールを作成することを妨げるものはありません。

アップデート（2017年3月16日）

幸い、ジャックは死んでいるので、Kotlin開発者には影響しません。

ジャックが未来であるなら、あなたは過去にコトリンで立ち往生するでしょう。現在Jackは、Java以外のソースをDalvikバイトコードにコンパイルできるプラグインをサポートしていません。そして、たとえそれができたとしても、JetBrainsはKotlinコンパイラに新しいバックエンドを追加する必要がありますが、これは簡単な作業ではありません。したがって、JillでKotlinを使用する必要があり、これは現在使用しているツールチェーンと非常によく似たものになります。

下の画像を見るとわかるように、Jackを明示的にオフにできない場合でも、プロジェクトをライブラリプロジェクトに変換してJillを使用することができます。そして、アプリケーションプロジェクトはこのライブラリプロジェクトを参照するだけです。

KotlinがJackでどのように動作するかを確認する唯一の方法は、おそらく実装されないでしょうが、JavaバックエンドをKotlinコンパイラー、つまりXtendのようなJavaコードを生成するバックエンドに追加することです。この場合、Kotlinコンパイラーによって生成されたコードは、他のJavaコードと同様にJackによって処理できます。

しかし、現時点では、Jackがリリースされたときに何をサポートするかは正確にはわかりません。多分何かが劇的に変化し、KotlinサポートをJackに追加することが可能になるでしょう。

今日登場したブログ投稿（KotlinのAndroidロードマップ）で述べたように、

現在、JackがKotlinで生成されたバイトコードを正しく処理できないいくつかの問題（196084および203531）がありますが、Googleチームと協力して問題を解決するか、回避策を提供する予定です。これが完了すると、すべてのクラスファイルを毎回翻訳するのではなく（古いAndroidツールで唯一可能な動作）、Jillを使用して変更されたクラスファイルのみを逐次コンパイル中に翻訳できます。

したがって、Kotlinは最終的にJack＆Jillをサポートし、そこから利益を得るでしょう。

最新のGoogleの発表に従って-

Java 8言語機能のサポートを現在のjavacおよびdxツールセットに直接追加し、Jackツールチェーンを廃止することを決定しました。この新しい方向性があれば、Javaクラスファイル形式に依存する既存のツールとプラグインは引き続き機能します。今後、Java 8言語機能はAndroidビルドシステムでネイティブにサポートされます。今後数週間でAndroid Studioの一部としてこれをリリースすることを目指しており、この決定を早期に共有したいと考えています。

最初に、Jackツールチェーンを介したJava 8サポートの追加をテストしました。アノテーションプロセッサ、バイトコードアナライザ、リライタの影響を検討したところ、私たちのコミュニティにとってジャックへの切り替えコストが高すぎることに気付きました。Jackツールチェーンを試していただき、素晴らしいフィードバックをお寄せいただきありがとうございます。新しいサポートがリリースされるまで、Jackを使用してJava 8コードをビルドし続けることができます。Jackからの移行は、ほとんどまたはまったく作業を必要としません。

そのため、ジャックツールチェーンがAndroid開発のデフォルトツールチェーンになることを心配する必要はありません。kotlinを引き続き使用するか、通常のjavac / dxツールセットを使用できます。

出典： AndroidでのJava 8言語機能サポートの将来

Kotlinの公式ブログからこのブログ投稿を既に見つけました：：KotlinのAndroidロードマップ

そこであなたはそれを伝える部分を見つけるでしょう：

Androidビルドのパフォーマンスを向上させるために次に計画していることは、Androidの新しいJack and Jillツールチェーンとの統合を提供することです。現在、JackがKotlinで生成されたバイトコードを正しく処理できないいくつかの問題（196084および203531）がありますが、Googleチームと協力して問題を解決するか、回避策を提供する予定です。これが完了すると、すべてのクラスファイルを毎回変換するのではなく（古いAndroidツールで可能な唯一の動作）、Jillを使用して、変更されたクラスファイルのみを逐次コンパイル中に変換できます。

したがって、@ LukasBergstromが言ったように、「過去のスタック」には何の問題もありません;-)

Redditこのトピックにリンクされたディスカッションを確認することもできます：ジャックとジルとのコトリンの状況は？

ハッピーコーディング。

Kotlinブログによると、リリース1.1-beta2の新機能セクション：

Jackツールチェーンが有効な場合のAndroidプロジェクトの構築のサポート（jackOptions {true}）;