Android N Java 8-Funktionen (Jack-Compiler) und Kotlin-Interop

Lesezeit: 9 Minuten

Benutzer-Avatar
Tudor Luca

Aktualisierung 3.
Kotlin ist JETZT OFFIZIELL FÜR ANDROID-ENTWICKLUNG UNTERSTÜTZT. VON GOOGLE. JAAAAAAA!

Aktualisierung 2: Es sieht aus wie JetBrains ist wirklich bestrebt, Kotlin für Android langfristig zu unterstützen. Ich bin ein glücklicher Kotlin-Benutzer :).

Aktualisieren: Hadi Hariri von JetBrains, erwähnt, dass sie einige Informationen zu diesem Thema veröffentlichen werden. Ich werde diesen Beitrag aktualisieren, sobald sie dies tun.

=== VERWORFENES ZEUG NÄCHSTES ===

Google hat gerade eine Vorschau für das kommende Android N mit einigen interessanten Funktionen veröffentlicht, von denen die bemerkenswertesten teilweise sind Java 8-Sprachunterstützung. Dies ist aufgrund der neuen möglich Jack-Werkzeugkette Google arbeitet daran.

Die aktuelle Toolchain mit Java oder kotlink:
Java (.java –> .class) –> dx (.class –> .dex)
kotlink (.kt –> .class) –> dx (.class –> .dex)

Neue Jack-Toolchain:
Jack (.java –> .jack –> .dex)

Ich gehe davon aus, dass Google die Herstellung vorantreiben wird Jack die Standard-Toolchain für die Android-Entwicklung. Aktualisieren: Jack ist jetzt veraltet. Ja.

Meine Frage ist, wie sich diese neue Toolchain in Zukunft auf mich als Mitarbeiter auswirken wird kotlin Benutzer für die Android-Entwicklung? Bleibe ich „in der Vergangenheit stecken“?

  • (kotlin_library(multiple*.kt) => .jar) dann Jill (.jar => Jayce) dann in Jack importieren (ähnlich wie andere (nicht Android) (einfache Java) Gläser)

    – Selvin

    10. März 2016 um 15:14 Uhr


  • Lesen der Dokumente: „Sie müssen nichts anders machen, um Jack zu verwenden – verwenden Sie einfach Ihre Standard-Makefile-Befehle, um den Baum oder Ihr Projekt zu kompilieren. Jack ist die Standard-Android-Build-Toolchain für M.“ – Quelle : source.android.com/source/jack.html sicherlich ist das ein Tippfehler und sie meinen ‘N’ nicht ‘M’ ?

    – Markieren

    3. Mai 2016 um 12:00 Uhr


  • Jack ist tot, freut euch 😛

    – EpicPandaForce

    24. April 2018 um 2:28 Uhr

Haftungsausschluss: Ich arbeite an Jack

Dies wird Sie nicht betreffen. Der Compiler von Kotlin erzeugt Java-6-Bytecode, den Jack/Jill problemlos importieren kann.

  • Kannst du ein paar Details dazu teilen? 🙂

    – Tudor Luca

    11. März 2016 um 1:18 Uhr

  • Aber wird Kotlin von der Leistungsoptimierung von Jack profitieren können? (mindestens einen Tag), weil Jack ziemlich großartig aussieht (ich kann gerade nicht auf einen Benchmark warten)

    – NitroG42

    11. März 2016 um 13:48 Uhr

  • Ich habe eine Videopräsentation eines Benchmarks vom Autor von proguard gesehen. Mit ein bisschen googeln können Sie es finden

    – sakis kaliakoudas

    11. März 2016 um 15:04 Uhr

  • Wir haben einige Schwierigkeiten beim Erstellen des Android-Projekts mit der angehängten Kotlin-stdlib. Sieht aus wie ein Fehler in Jill/Jack. Könnten Sie sich das bitte ansehen? code.google.com/p/android/issues/detail?id=196084

    – Janex

    11. März 2016 um 15:15 Uhr


  • Bedeutet das, dass Jill keinen Java 8-Bytecode akzeptiert? Was ist mit Bibliotheksmodulen? Wenn sie in .aar kompiliert und dann von Jill importiert werden, können sie dann auch Java 8 nicht verwenden? Bedeutet dies, dass neue Java-Funktionen nur für projektinterne .java-Quellen verfügbar sind?

    – fern.be

    15. März 2016 um 3:41 Uhr

@Pavel Dudka

Jack – ist ein Compiler. Ähnlich wie Javac, aber etwas anders:

Geben Sie hier die Bildbeschreibung ein

Wie Sie sehen können, kompiliert Jack den Java-Quellcode direkt in die Dex-Datei! Wir haben keine *.class-Zwischendateien mehr, daher wird das dx-Tool nicht benötigt!

Aber warte! Was ist, wenn ich eine Bibliothek eines Drittanbieters in mein Projekt einbinde (die als Sammlung von .class-Dateien geliefert wird)?

Und da kommt Jill ins Spiel:

Geben Sie hier die Bildbeschreibung ein

Jill kann Klassendateien verarbeiten und sie in ein spezielles Jayce-Format umwandeln, das als Eingabe für den Jack-Compiler verwendet werden kann.

Lassen Sie uns jetzt einen Moment beiseite treten und nachdenken… Was wird mit all den coolen Plugins passieren, nach denen wir so süchtig geworden sind? Sie alle brauchen .class-Dateien und der Jack-Compiler hat diese nicht mehr …

Glücklicherweise bietet Jack einige der für uns wichtigen Funktionen sofort an:

  • Retrolambda – wird nicht benötigt. Jack kann richtig mit Lambdas umgehen
  • Proguard – es ist jetzt in Jack eingebrannt, sodass Sie immer noch Verschleierung und Minimierung verwenden können

Vorteile:

Jack unterstützt die Programmiersprache Java 1.7 und integriert zusätzliche Funktionen, die unten beschrieben werden.

  • Prädizierung

    Beim Generieren einer JACK-Bibliotheksdatei wird die .dex-Datei der Bibliothek generiert und in der .jack-Bibliotheksdatei als Prädex gespeichert. Beim Kompilieren verwendet JACK den Prädex aus jeder Bibliothek wieder. Alle Bibliotheken sind vorindiziert.

  • Inkrementelle Kompilierung

    Inkrementelle Kompilierung bedeutet, dass nur Komponenten, die seit der letzten Kompilierung geändert wurden, und ihre Abhängigkeiten neu kompiliert werden. Die inkrementelle Kompilierung kann erheblich schneller sein als eine vollständige Kompilierung, wenn Änderungen auf nur eine begrenzte Gruppe von Komponenten beschränkt sind.

  • Umpacken

    JACK verwendet Jarjar-Konfigurationsdateien, um das Neupacken durchzuführen.

  • Multidex-Unterstützung

    Da dex-Dateien auf 65.000 Methoden beschränkt sind, müssen Apps mit über 65.000 Methoden in mehrere dex-Dateien aufgeteilt werden. (Weitere Informationen zu Multidex finden Sie unter „Apps mit über 65.000 Methoden erstellen“.)

Nachteile:

  • Die Transform-API wird von Jack nicht unterstützt – es gibt keinen zwischengeschalteten Java-Bytecode, den Sie ändern können, daher werden einige Plugins, die ich hier nicht erwähnt habe, nicht mehr funktionieren
  • Die Verarbeitung von Anmerkungen wird derzeit nicht von Jack unterstützt. Wenn Sie also stark auf Bibliotheken wie Dagger, AutoValue usw. angewiesen sind, sollten Sie es sich zweimal überlegen, bevor Sie zu Jack wechseln. BEARBEITEN: Wie von Jake Wharton hervorgehoben, unterstützt Jack in N Preview die Verarbeitung von Anmerkungen, ist aber noch nicht über Gradle verfügbar.
  • Lint-Detektoren, die auf Java-Bytecode-Ebene arbeiten, werden nicht unterstützt.
  • Jacoco wird nicht unterstützt – naja ich persönlich finde jacoco fragwürdig (es zeigt nicht wirklich was man sehen will), kann also ganz darauf verzichten
  • Dexguard – Unternehmensversion von Proguard wird derzeit nicht unterstützt

  • gilt die ‘Anmerkungsverarbeitung wird derzeit nicht von Jack unterstützt’ noch im September 2016? Es scheint, als ob es jetzt unterstützt wird …

    – ticofab

    8. September 2016 um 10:57 Uhr

  • es wird unterstützt, aber es gibt noch Fehler: z. B. funktioniert die Datenbindung noch nicht: siehe Android #210615

    – TmTron

    25. Oktober 2016 um 8:02 Uhr

  • Beachten Sie, dass die Annotationsverarbeitung von Jack NICHT vollständig unterstützt wird – sie befindet sich in demselben heruntergekommenen Zustand wie im Eclipse Compiler, auf dem Jack basiert (Mehrere Methoden sind als Platzhalter implementiert, die beim Aufrufen Ausnahmen auslösenes gibt zahlreiche nicht behobene Fehler, die auf dem ECJ-Bugtracker eingereicht wurden).

    – Benutzer1643723

    22. November 2016 um 9:48 Uhr

Benutzer-Avatar
Teovald

Google wird Jack nicht als Standard-Tool durchsetzen, aber Jack and Jill.
Das Kompilieren von .class-Dateien zum Dex mit Jill ist gekommen, um zu bleiben. Ansonsten können Sie sich von jar/aar-Bibliotheken verabschieden.

Ob Jack oder Jill langsamer sein werden, steht noch zur Debatte. Das Android-Team hofft, dass Jack schneller sein wird als der aktuelle Build-Prozess, aber das ist derzeit nicht der Fall

Darüber hinaus sind Jack und Dex offen verfügbar, nichts hindert das Kotlin-Team daran, ein Tool zu schreiben, das .jack- oder .dex-Dateien aus dem Kotlin-Quellcode ausgibt.

Benutzer-Avatar
Michael

UPDATE (16.03.2017)

Glücklicherweise ist Jack tot und wird die Kotlin-Entwickler nicht betreffen.


Wenn Jack die Zukunft ist, dann bleiben Sie mit Kotlin in der Vergangenheit stecken. Derzeit unterstützt Jack keine Plugins, die Nicht-Java-Quellen in Dalvik-Bytecode kompilieren können. Und selbst wenn dies der Fall wäre, müsste JetBrains dem Kotlin-Compiler ein neues Backend hinzufügen, was keine triviale Aufgabe ist. Sie müssen also Kotlin mit Jill verwenden, und es wird der Toolchain, die Sie jetzt verwenden, sehr ähnlich sein.

Wie Sie im Bild unten sehen können, können Sie das Projekt auch dann in ein Bibliotheksprojekt konvertieren, um Jill zu verwenden, wenn es unmöglich ist, Jack explizit zu deaktivieren. Und das Anwendungsprojekt wird nur auf dieses Bibliotheksprojekt verweisen.

Anwendungserstellung für Jack und Jill

Die einzige Möglichkeit, die ich sehe, wie Kotlin mit Jack zusammenarbeiten kann, was wahrscheinlich nicht implementiert wird, besteht darin, dem Kotlin-Compiler ein Java-Backend hinzuzufügen, dh ein Backend, das Java-Code generiert Erweitern. In diesem Fall kann der vom Kotlin-Compiler generierte Code von Jack wie jeder andere Java-Code verarbeitet werden.

Aber im Moment wissen wir nicht genau, was Jack unterstützen wird, wenn es veröffentlicht wird. Vielleicht ändert sich etwas dramatisch und das Hinzufügen von Kotlin-Unterstützung zu Jack wird möglich.

Wie im Blogbeitrag gesagt (Kotlins Android-Roadmap), die heute erschienen ist:

Im Moment gibt es einige Probleme, die Jack daran hindern, von Kotlin generierten Bytecode korrekt zu verarbeiten (196084 und 203531), aber wir planen, mit dem Google-Team zusammenzuarbeiten, um die Probleme entweder zu lösen oder auf unserer Seite Problemumgehungen bereitzustellen. Sobald dies erledigt ist, Wir können nur geänderte Klassendateien mit Jill übersetzen während der inkrementellen Kompilierung, anstatt jedes Mal alle Klassendateien zu übersetzen (was das einzig mögliche Verhalten in den alten Android-Tools ist).

Kotlin wird also schließlich Jack & Jill unterstützen und davon profitieren.

Benutzer-Avatar
Gemeinschaft

Gemäß der neuesten Google-Ankündigung –

Wir haben uns entschieden, Unterstützung für Java 8-Sprachfunktionen direkt in den aktuellen javac- und dx-Satz von Tools aufzunehmen und die Jack-Toolchain zu verwerfen. Mit dieser neuen Richtung sollten bestehende Tools und Plugins, die vom Dateiformat der Java-Klasse abhängig sind, weiterhin funktionieren. In Zukunft werden Java 8-Sprachfunktionen vom Android-Buildsystem nativ unterstützt. Wir beabsichtigen, dies in den kommenden Wochen als Teil von Android Studio zu starten, und wir wollten diese Entscheidung frühzeitig mit Ihnen teilen.

Wir haben zunächst das Hinzufügen von Java 8-Unterstützung über die Jack-Toolchain getestet. Im Laufe der Zeit stellten wir fest, dass die Kosten für den Wechsel zu Jack für unsere Community zu hoch waren, als wir die betroffenen Annotationsprozessoren, Bytecode-Analysatoren und Rewriter berücksichtigten. Vielen Dank, dass Sie die Jack-Toolchain ausprobiert und uns tolles Feedback gegeben haben. Sie können Jack weiterhin verwenden, um Ihren Java 8-Code zu erstellen, bis wir die neue Unterstützung veröffentlichen. Die Migration von Jack sollte wenig oder gar keine Arbeit erfordern.

Wir müssen uns also keine Sorgen machen, dass die Jack-Toolchain zur Standard-Toolchain für die Android-Entwicklung wird. Sie können weiterhin kotlin oder den normalen javac/dx-Werkzeugsatz verwenden.

Quelle : Zukunft der Java 8-Sprachfunktionsunterstützung auf Android

Benutzer-Avatar
piotrek1543

Ich habe diesen Blogbeitrag bereits aus dem offiziellen Kotlin-Blog gefunden: : Kotlins Android-Roadmap

Dort würden Sie einen Teil finden, der Folgendes besagt:

Das nächste, was wir zur Verbesserung der Android-Build-Leistung planen, ist die Bereitstellung einer Integration mit dem neuen Android Werkzeugkette von Jack und Jill. Im Moment gibt es einige Probleme, die Jack daran hindern, von Kotlin generierten Bytecode korrekt zu verarbeiten (196084 und 203531), aber wir planen, mit dem Google-Team zusammenzuarbeiten, um die Probleme entweder zu lösen oder auf unserer Seite Problemumgehungen bereitzustellen. Sobald dies erledigt ist, können wir nur geänderte Klassendateien mit Jill während der inkrementellen Kompilierung übersetzen, anstatt jedes Mal alle Klassendateien zu übersetzen (was das einzig mögliche Verhalten in den alten Android-Tools ist).

Also, wie @LukasBergstrom sagte, es wird kein Problem damit geben, in der Vergangenheit zu bleiben 😉

Sie können auch überprüfen Reddit Diskussion zu diesem Thema: Wie ist der Status von Kotlin mit Jack und Jill?

Viel Spaß beim Codieren.

1282660cookie-checkAndroid N Java 8-Funktionen (Jack-Compiler) und Kotlin-Interop

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy