Fonctionnalités Android N Java 8 (compilateur Jack) et interopérabilité Kotlin

Mise à jour 3. KOTLIN EST MAINTENANT OFFICIELLEMENT SOUTENU POUR LE DÉVELOPPEMENT D'ANDROID . PAR GOOGLE. YAAAAAAAAS!

Mise à jour 2 : Il semble que JetBrains s'engage vraiment à soutenir Kotlin pour Android à long terme . Je suis un utilisateur heureux de kotlin :).

Mise à jour : Hadi Hariri, de JetBrains, a mentionné qu'ils allaient publier des informations sur ce sujet . Je mettrai à jour ce post une fois qu'ils le feront.

=== TRUCS DÉPRÉCIÉS SUIVANT ===

Google vient de publier un aperçu du prochain Android N avec des fonctionnalités intéressantes, la plus notable étant la prise en charge partielle du langage Java 8 . Cela est possible grâce à la nouvelle chaîne d'outils Jack sur laquelle Google travaille.

La chaîne d'outils actuelle utilisant javac ou kotlinc :
javac ( .java-> .class) -> dx ( .class-> .dex)
kotlinc ( .kt-> .class) -> dx ( .class-> .dex)

Nouvelle chaîne d'outils Jack:
Jack ( .java-> .jack-> .dex)

Je suppose que Google ira de l'avant pour faire de Jack la chaîne d'outils par défaut pour le développement Android. Mise à jour: Jack est désormais obsolète . Oui.

Ma question est de savoir comment cette nouvelle chaîne d'outils m'affectera, à l'avenir, en tant qu'utilisateur de kotlin pour le développement Android? Vais-je rester "coincé dans le passé"?

avertissement: je travaille sur Jack

Cela ne vous affectera pas. Le compilateur de Kotlin produit du bytecode Java 6, que Jack / Jill peut très bien importer.

@Pavel Dudka

Jack - est un compilateur. Similaire à javac, mais il fait une chose légèrement différente:

Comme vous pouvez le voir, Jack compile le code source Java directement dans un fichier Dex! Nous n'avons plus de fichiers intermédiaires * .class, donc l'outil dx n'est pas nécessaire!

Mais attendez! Que faire si j'inclus une bibliothèque tierce dans mon projet (qui se présente sous la forme d'une collection de fichiers .class)?

Et c'est là que Jill entre en jeu:

Jill peut traiter les fichiers de classe et les transformer au format Jayce spécial qui peut être utilisé comme entrée pour le compilateur Jack.

Alors maintenant, laissons-nous de côté pendant une seconde et réfléchissons ... Que va-t-il arriver à tous ces plugins sympas auxquels nous sommes tellement accro? Ils ont tous besoin de fichiers .class et le compilateur Jack ne les a plus ...

Heureusement, Jack fournit certaines de ces fonctionnalités importantes pour nous:

• Retrolambda - ne sera pas nécessaire. Jack peut gérer correctement les lambdas
• Proguard - il est intégré dans Jack maintenant, vous pouvez donc toujours utiliser l'obscurcissement et la minimisation

Avantages:

Jack prend en charge le langage de programmation Java 1.7 et intègre des fonctionnalités supplémentaires décrites ci-dessous.

• Prédexage

  Lors de la génération d'un fichier de bibliothèque JACK, le .dex de la bibliothèque est généré et stocké dans le fichier de bibliothèque .jack en tant que pré-dex. Lors de la compilation, JACK réutilise le pré-dex de chaque bibliothèque. Toutes les bibliothèques sont prédexcitées.

• Compilation incrémentale

  La compilation incrémentielle signifie que seuls les composants qui ont été touchés depuis la dernière compilation, et leurs dépendances, sont recompilés. La compilation incrémentielle peut être beaucoup plus rapide qu'une compilation complète lorsque les modifications sont limitées à un ensemble limité de composants.

• Reconditionnement

  JACK utilise les fichiers de configuration jarjar pour effectuer le reconditionnement.

• Prise en charge Multidex

  Étant donné que les fichiers dex sont limités à 65K méthodes, les applications avec plus de 65K méthodes doivent être divisées en plusieurs fichiers dex. (Voir «Création d'applications avec plus de 65 000 méthodes» pour plus d'informations sur le multidex.)

Désavantages:

• L'API Transform n'est pas prise en charge par Jack - il n'y a pas de bytecode Java intermédiaire que vous pouvez modifier, donc certains plugins que je n'ai pas mentionnés ici cesseront de fonctionner
• Le traitement des annotations n'est actuellement pas pris en charge par Jack, donc si vous dépendez fortement de bibliothèques comme Dagger, AutoValue, etc., vous devriez réfléchir à deux fois avant de passer à Jack. EDIT: Comme l'a souligné Jake Wharton, Jack in N Preview prend en charge le traitement des annotations, mais il n'est pas encore exposé via Gradle.
• Les détecteurs de charpie qui fonctionnent au niveau du bytecode Java ne sont pas pris en charge.
• Jacoco n'est pas pris en charge - eh bien, personnellement, je trouve Jacoco discutable (il ne montre pas vraiment ce que vous voulez voir), donc je peux totalement vivre sans lui
• Dexguard - La version entreprise de Proguard n'est actuellement pas prise en charge

Google ne va pas pousser Jack comme outil par défaut, mais Jack and Jill.
Compiler des fichiers .class à dex avec Jill est là pour rester. Sinon, vous pouvez dire adieu aux bibliothèques jar / aar.

La question de savoir si Jack ou Jill sera plus lent est encore en débat. L'équipe Android espère que Jack sera plus rapide que le processus de construction actuel, mais ce n'est pas le cas pour le moment

De plus, Jack et Dex sont disponibles à l'air libre, rien n'empêche l'équipe kotlin d'écrire un outil émettant des fichiers .jack ou .dex à partir du code source kotlin.

MISE À JOUR (16/03/2017)

Heureusement, Jack est mort et cela n'affectera donc pas les développeurs de Kotlin.

Si Jack est l'avenir, vous resterez coincé dans le passé avec Kotlin. Actuellement, Jack ne prend pas en charge les plugins qui peuvent compiler des sources non Java dans le bytecode Dalvik. Et même si c'était le cas, JetBrains aurait besoin d'ajouter un nouveau backend au compilateur Kotlin, ce qui n'est pas une tâche triviale. Vous devrez donc utiliser Kotlin avec Jill et ce sera quelque chose de très similaire à la chaîne d'outils que vous utilisez maintenant.

Comme vous pouvez le voir dans l'image ci-dessous, même s'il est impossible de désactiver explicitement Jack, vous pourrez toujours convertir le projet en projet de bibliothèque pour utiliser Jill. Et le projet d'application fera simplement référence à ce projet de bibliothèque.

La seule façon dont je vois comment Kotlin peut travailler avec Jack, qui ne sera probablement pas implémenté, est d'ajouter un backend Java au compilateur Kotlin, c'est-à-dire un backend qui génère du code Java comme Xtend . Dans ce cas, le code généré par le compilateur Kotlin peut être traité par Jack comme n'importe quel autre code Java.

Mais pour le moment, nous ne savons pas exactement ce que Jack soutiendra lors de sa sortie. Peut-être que quelque chose va changer radicalement et ajouter le support de Kotlin à Jack deviendra possible.

Comme indiqué dans le billet de blog ( Feuille de route Android de Kotlin ) paru aujourd'hui:

À l'heure actuelle, certains problèmes empêchent Jack de gérer correctement le bytecode généré par Kotlin ( 196084 et 203531 ), mais nous prévoyons de travailler avec l'équipe Google pour résoudre les problèmes ou fournir des solutions de contournement de notre côté. Une fois que cela est fait, nous serons en mesure de traduire uniquement les fichiers de classe modifiés en utilisant Jill lors de la compilation incrémentielle, par opposition à la traduction de tous les fichiers de classe à chaque fois (ce qui est le seul comportement possible dans l'ancien outil Android).

Donc Kotlin finira par soutenir Jack & Jill et en bénéficiera.

Selon la dernière annonce Google -

Nous avons décidé d'ajouter la prise en charge des fonctionnalités du langage Java 8 directement dans l'ensemble d'outils javac et dx actuel, et de rendre obsolète la chaîne d'outils Jack. Avec cette nouvelle direction, les outils et plugins existants dépendants du format de fichier de classe Java devraient continuer à fonctionner. À l'avenir, les fonctionnalités du langage Java 8 seront prises en charge nativement par le système de construction Android. Nous visons à le lancer dans le cadre d'Android Studio dans les semaines à venir, et nous voulions partager cette décision au plus tôt avec vous.

Nous avons d'abord testé l'ajout de la prise en charge de Java 8 via la chaîne d'outils Jack. Au fil du temps, nous avons réalisé que le coût du passage à Jack était trop élevé pour notre communauté lorsque nous avons considéré les processeurs d'annotation, les analyseurs de bytecode et les réécriveurs concernés. Merci d'avoir essayé la chaîne d'outils Jack et de nous avoir donné d'excellents commentaires. Vous pouvez continuer à utiliser Jack pour créer votre code Java 8 jusqu'à ce que nous publions le nouveau support. La migration depuis Jack ne devrait nécessiter que peu ou pas de travail.

Nous n'avons donc pas à nous soucier du fait que la chaîne d'outils Jack devienne la chaîne d'outils par défaut pour le développement Android. Vous pouvez continuer à utiliser kotlin ou utiliser un ensemble d'outils javac / dx normal.

Source: Prise en charge des fonctionnalités du langage Future of Java 8 sur Android

J'ai déjà trouvé ce billet de blog sur le blog officiel de Kotlin:: Feuille de route Android de Kotlin

Vous y trouverez une partie qui dit que:

La prochaine chose que nous prévoyons de faire pour améliorer les performances de construction d'Android est de fournir une intégration avec la nouvelle chaîne d'outils Jack et Jill d'Android . À l'heure actuelle, certains problèmes empêchent Jack de gérer correctement le bytecode généré par Kotlin ( 196084 et 203531 ), mais nous prévoyons de travailler avec l'équipe Google pour résoudre les problèmes ou fournir des solutions de contournement de notre côté. Une fois que cela est fait, nous pourrons traduire uniquement les fichiers de classe modifiés en utilisant Jill lors de la compilation incrémentielle, par opposition à la traduction de tous les fichiers de classe à chaque fois (ce qui est le seul comportement possible dans l'ancien outil Android).

Donc, comme l'a dit @LukasBergstrom, il n'y aura aucun problème avec "coincé dans le passé" ;-)

Vous pouvez également consulter la Redditdiscussion liée à ce sujet: Quel est le statut de Kotlin avec Jack et Jill?

Bon codage.

Selon le blog Kotlin , section Nouvelles fonctionnalités de la version 1.1-beta2:

Prise en charge de la création de projets Android lorsque la chaîne d'outils Jack est activée (jackOptions {true});