Android N Java 8 fonctionnalités (compilateur Jack) et interopérabilité Kotlin)
Mise à jour 3. KOTLIN IS MAINTENANT OFFICIELLEMENT PRIS EN CHARGE Android DÉVELOPPEMENT . PAR GOOGLE. YAAAAAAAAS!
Mise à jour 2 : il ressemble à JetBrains est vraiment engagé à soutenir Kotlin pour Android à long terme) . Je suis un utilisateur heureux de kotlin :).
Mise à jour : Hadi Hariri, de JetBrains, mentionné qu'ils vont publier des informations sur ce sujet . Je mettrai à jour ce post une fois qu'ils le feront.
=== DEPRECATED STUFF NEXT ===
Google vient de publier un aperçu de la prochaine Android N avec des fonctionnalités intéressantes, la plus notable étant partielle prise en charge du langage Java 8 . Cela est possible grâce à la nouvelle - Jack toolchain Google travaille sur.
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 va pousser à faire de Jack la chaîne d'outils par défaut pour Android développement. Mise à jour: Jack est maintenant obsolète . Oui.
Ma question est de savoir comment cette nouvelle chaîne d'outils m'affectera, à l'avenir, en tant qu'utilisateur kotlin pour Android development? Vais-je être "coincé dans le passé"?
mentions légales: je travaille sur Jack
Cela ne vous affectera pas. Le compilateur de Kotlin produit Java 6 bytecode, que Jack/Jill peut importer très bien.
@ 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 Java directement dans le 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 en format Jayce spécial qui peut être utilisé comme entrée pour le compilateur Jack.
Alors maintenant, mettons-nous de côté pendant une seconde et pensons ... 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 n'en a plus ...
Heureusement, Jack fournit certaines de ces fonctionnalités importantes pour nous:
- Retrolambda - ne sera pas nécessaire. Jack peut gérer les lambdas correctement
- Proguard - il est intégré à Jack maintenant, vous pouvez donc toujours utiliser l'obscurcissement et la minimisation
Avantages:
Jack prend en charge Java langage de programmation 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édéfinies.
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 considérablement plus rapide qu'une compilation complète lorsque les modifications sont limitées à un ensemble limité de composants.
Reconditionnement
JACK utilise des fichiers de configuration jarjar pour effectuer le reconditionnement.
Prise en charge de 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.)
Inconvénients:
- L'API de transformation n'est pas prise en charge par Jack - il n'y a pas d'intermédiaire Java bytecode 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 peluches qui fonctionnent au niveau Java niveau de bytecode ne sont pas pris en charge.
- Jacoco n'est pas pris en charge - eh bien, je trouve personnellement Jacoco discutable (il ne montre pas vraiment ce que vous voulez voir), donc peut totalement vivre sans
- Dexguard - la version entreprise de Proguard n'est pas actuellement prise en charge
Google ne va pas pousser Jack comme outil par défaut, mais Jack and Jill.
La compilation de fichiers .class en dex avec Jill est là pour rester. Sinon, vous pouvez dire au revoir aux bibliothèques jar/aar.
La question de savoir si Jack ou Jill sera plus lente est encore à débattre. L'équipe Android espère que jack sera plus rapide que le processus de construction actuel, mais ce n'est pas le cas en ce moment
De plus, Jack et Dex sont disponibles en plein air, 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 serez coincé dans le passé avec Kotlin. Actuellement, Jack ne prend pas en charge les plugins qui peuvent compiler des sources non Java en bytecode Dalvik. Et même si c'était le cas, JetBrains devrait 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 fonctionner 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 Java code comme Xtend . Dans ce cas, le code généré par le compilateur Kotlin peut être traité par Jack comme tout autre code Java 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 ( Kotlin's Android Roadmap ) 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 de Google pour résoudre le problème. problèmes ou fournir des solutions de contournement de notre côté. Une fois cela fait, nous pourrons traduire uniquement les fichiers de classe modifiés en utilisant Jill pendant la compilation incrémentielle, par opposition à la traduction de tous les fichiers de classe à chaque fois ( qui est le seul comportement possible dans l'ancien Android).
Kotlin soutiendra donc Jack & Jill et en tirera des avantages.
Selon la dernière annonce de Google -
Nous avons décidé d'ajouter la prise en charge de Java 8 fonctionnalités du langage directement dans l'ensemble d'outils javac et dx actuel, et de déprécier la chaîne d'outils Jack. Avec cette nouvelle direction, les outils et plugins existants dépendant de la Java format de fichier de classe devrait continuer à fonctionner. À l'avenir, Java 8 fonctionnalités de langage seront prises en charge nativement par le Android Nous avons l'intention de lancer cela dans le cadre de Android Studio dans les semaines à venir, et nous voulions partager cette décision avec vous très tôt.
Nous avons initialement 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éécrivains impactés. . Merci d'avoir essayé la chaîne d'outils Jack et de nous avoir fait part de vos commentaires. Vous pouvez continuer à utiliser Jack pour créer votre code Java 8 jusqu'à la sortie de la nouvelle prise en charge. La migration à partir de Jack devrait nécessiter peu ou pas de travail .
Nous n'avons donc pas à nous soucier de la chaîne d'outils Jack devenant la chaîne d'outils par défaut pour Android. Vous pouvez continuer à utiliser kotlin ou utiliser un ensemble d'outils javac/dx normal.
Source: Futur de Java 8 Prise en charge des fonctionnalités linguistiques sur Android
J'ai déjà trouvé cet article de blog sur le blog officiel de Kotlin:: Kotlin’s Android Roadmap
Vous y trouverez une partie qui dit que:
La prochaine chose que nous prévoyons de faire pour améliorer Android fournissent une intégration avec la nouvelle chaîne d'Android Jack and Jill toolchain . À 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 de Google pour résoudre les problèmes ou fournir des solutions de contournement de notre côté. est fait, nous ne pourrons traduire que les fichiers de classe modifiés à l'aide de Jill lors de la compilation incrémentielle, au lieu de traduire tous les fichiers de classe à chaque fois (ce qui est le seul comportement possible dans l'ancien Android tooling ).
Donc, comme l'a dit @LukasBergstrom, il n'y aura pas de problème avec "coincé dans le passé" ;-)
Vous pouvez également consulter Reddit discussion liée à ce sujet: Quel est le statut de Kotlin avec Jack et Jill?
Codage heureux.
Selon le blog Kotlin , version 1.1-beta2 Nouvelles fonctionnalités:
Prise en charge de la construction Android projets lorsque la chaîne d'outils Jack est activée (jackOptions {true});