Comment Jack (Compilateur Java Android) affectera les développeurs Scala

Question

Maintenant, avec l'annonce de la Prise de Google a précisé un proche avenir de Java par rapport à Android. Mais quelles sont les implications de la Scala et d'autres JVM langages basés sur les développeurs. En particulier:

1. Scala est-il de la magie grâce à un compilateur qui produit du bytecode Java. Mais Jack la chaîne n'a pas affaire à du bytecode. Va générer du bytecode à gagner tous les avantages de l'optimisation de la Prise du traitement?
2. À partir de Scala 12 seulement Java 8+ est pris en charge. C'est le bytecode généré est de Java 8+ trop. Peut-Jack d'utiliser Java 8 bytecode (sans ou avec des limites)?
3. Peut nouvelle prise en charge de Java 8 dispose d'être utilisé pour le développement pour les anciennes versions d'Android (minSdkVersion < 'N') ou, devrais-je maintenir la branche distincte pour chaque version de Java? (il n'est pas clair à partir de la documentation).

Toutes ces questions se résument à une seule: Peut Scala être utilisé pour le développement Android à l'avenir sans pour autant sacrifier les avantages de la nouvelle Scala de fonctionnalités et de nouvelles Android outil de la chaîne d'approvisionnement?

Liées à la lecture:

• Java 8 Fonctionnalités De Langage

• Jack (Java Android Compilateur Kit)

• Nouveau Android Outil de la Chaîne d' - Jack et Jill

• Le Jack et Jill système de build (diapositives)

• Bonjour tout le Monde, de rencontrer nos nouveaux expérimentale de la chaîne d'

• Scala 2.12 feuille de route

merci de partager des liens dans les commentaires ou réponses

Questions connexes:

• Android N Java 8 fonctions (Jack compilateur) et Kotlin interop

Connexes:

• scala-sur-android-discussion de groupe

S'il vous plaît voter pour Jack outil de demande de fonctionnalité:

• Le Support de Java 8 bytecode (bibliothèques) par Jill
• Support de Java 8 fonctionnalités de langage

---

EDIT:

Je suis en train de raison (PAS de réponse) ma question en espérant que les experts corriger moi si je me trompe.

Ci-dessous est une hypothétique flux de Jack version avec quelques blocs supplémentaires qui a été ajouté en se basant sur ma logique, et ce que j'ai appris de docs.

Hypothèse de Base est que Dalvik prend en charge jusqu'à Java 7 instructions bytecode. Si c'est correct de Java 8 instructions ne peuvent pas être directement transmis à Dalvik, ils devraient être en quelque sorte transformé en Java 7. (Peut-être quelque chose de similaire à la Scala compilateur le fait toujours).

Que la question est de savoir où est cette transformation qui se passe? Semble Jill ne peut pas traiter de Java 8 bytecode comme pour l'instant, de sorte que, éventuellement, se produit dans le bloc (3) de l'hypothétique flux. Si c'est exact que la seule source Java, les fichiers de projet sont soumis à la transformation et la réponse à la 2ème question est: "Pas de. Java 8 classes de bibliothèques ne peut pas être utilisé jusqu'à ce que Jill sera en mesure de le faire (si c'est possible). Qui est, nous ne pouvons pas utiliser Scala 12+.

Si tout le code, l'optimisation est effectuée dans le bloc (6) que la réponse à la 1ère question est Oui. Scala code converti à la bibliothèque .jar peuvent bénéficier de la Prise des optimisations. Mais au préalable, il doit être transformé .jayce (AST-comme représentation) qui permettront d'augmenter le temps de construction.

Et enfin Jack produit .dex bytecode Dalvik pour maintenir la compatibilité avec les anciens Dalvik temps d'exécution (ART consomme bytecode Dalvik trop). Donc la réponse à la 3-d question est: Oui, Java 8 fonctions peuvent être utilisées. Mais seulement dans le projet des sources Java. L'application est toujours compatible avec n'importe quel moment de l'exécution. Mais Java 8 avantages sont abandonnées en raison de la conversion de Java 7 (bytecode Dalvik).

---

Answer 1

Il est important de comprendre qu'il y a 2 outil présenté:

• Jack: Un nouveau compilateur de remplacer le complexe javac + proguard + dx

• Jill: Une bibliothèque de liens qui sera en mesure de lier actuellement bibliothèques compilées (.classe) et plus.
  Voir http://tools.android.com/tech-docs/jackandjill

Il semble donc qu'il y a 2 problème ici:

• Scala de compatibilité:
  Scala ne sera pas pris en charge par Jack, Jack compile le code source Java.
  Cependant Scala 2.11 compile à la version 1.6 de Java bytecode et, par conséquent, Jill sera en mesure de reprendre le code et de le convertir à la prise de fichiers pour nourrir la Prise de compilateur.
  Voir Android N Java 8 fonctions (Jack compilateur) et Kotlin interop (Kotlin que la même question que le Scala comme c'est une JVM de la langue)

• Java 8, et donc Scala 2.12+, compatibilité:
  Cette partie est en cours de développement, si Jack/Jill prend en charge Java 8, il sera également en charge de la Scala 2.12+ (par Jill). Si non, Java 8, les développeurs sont dans le même bateau que Scala 2.12 développeurs.
  Dans le cas de Prise en charge Java 8, mais pas Jill, puis Java 8 bibliothèques de développeurs sera dans le même bateau que Scala 2.12 développeurs.
  Voir https://www.guardsquare.com/blog/DroidconLondon2015

Answer 2

Joan a raison, mais je pense que Jill aura un support pour Java 8 à un moment donné, sinon il sera impossible d'utiliser Java 8 dans des bibliothèques Android qui seront consommées par des applications Android, car elles empaquetent leur code dans un fichier jar à l'intérieur de aar et je ne vois pas ce changement de format se produire n'importe où bientôt. Quoi qu’il en soit, nous ne pouvons que deviner, car Google est actuellement une boîte noire en ce qui concerne ce type de modifications.