Funkcje Android N Java 8 (kompilator Jacka) i współpraca z Kotlin

Aktualizacja 3. KOTLIN JEST TERAZ OFICJALNIE WSPIERANY DLA ROZWOJU ANDROIDA . PRZEZ GOOGLE. YAAAAAAAAS!

Aktualizacja 2 : Wygląda na to, że JetBrains jest naprawdę zaangażowany we wspieranie Kotlin na Androida w dłuższej perspektywie . Jestem szczęśliwym użytkownikiem kotlina :).

Aktualizacja : Hadi Hariri z JetBrains wspomniał, że zamierzają wydać trochę informacji na ten temat . Zaktualizuję ten post, gdy to zrobią.

=== WYCOFANE RZECZY NASTĘPNE ===

Firma Google właśnie udostępniła wersję zapoznawczą nadchodzącego Androida N z kilkoma interesującymi funkcjami, z których najbardziej godną uwagi jest częściowa obsługa języka Java 8 . Jest to możliwe dzięki nowemu łańcuchowi narzędzi Jack, nad którym pracuje Google.

Bieżący łańcuch narzędzi przy użyciu javac lub kotlinc :
javac ( .java-> .class) -> dx ( .class-> .dex)
kotlinc ( .kt-> .class) -> dx ( .class-> .dex)

Nowy łańcuch narzędzi Jacka:
Jack ( .java-> .jack-> .dex)

Zakładam, że Google będzie dążyć do uczynienia Jacka domyślnym łańcuchem narzędzi do tworzenia aplikacji na Androida. Aktualizacja: Jack jest teraz przestarzały . Tak.

Moje pytanie brzmi: w jaki sposób ten nowy łańcuch narzędzi wpłynie na mnie w przyszłości jako użytkownika kotlin do tworzenia aplikacji na Androida? Czy „utknę w przeszłości”?

zastrzeżenie: pracuję nad Jackiem

To na ciebie nie wpłynie. Kompilator Kotlina tworzy kod bajtowy Java 6, który Jack / Jill może dobrze zaimportować.

@Pavel Dudka

Jack - jest kompilatorem. Podobny do javac, ale działa nieco inaczej:

Jak widać, Jack kompiluje kod źródłowy Javy bezpośrednio do pliku Dex! Nie mamy już plików pośrednich * .class, więc narzędzie dx nie jest potrzebne!

Ale poczekaj! Co się stanie, jeśli dołączę do projektu bibliotekę innej firmy (która jest zbiorem plików .class)?

I wtedy do gry wkracza Jill:

Jill może przetwarzać pliki klas i przekształcać je w specjalny format Jayce, który może służyć jako dane wejściowe dla kompilatora Jacka.

Więc teraz odsuńmy się na chwilę i zastanówmy się… Co się stanie z tymi wszystkimi fajnymi wtyczkami, od których jesteśmy tak uzależnieni? Wszyscy potrzebują plików .class, a kompilator Jacka już ich nie ma ...

Na szczęście Jack udostępnia kilka z tych ważnych dla nas funkcji po wyjęciu z pudełka:

• Retrolambda - nie będzie potrzebna. Jack może poprawnie obsługiwać lambdy
• Proguard - jest teraz wypiekany w Jacku, więc nadal możesz używać zaciemniania i minimalizacji

Zalety:

Jack obsługuje język programowania Java 1.7 i integruje dodatkowe funkcje opisane poniżej.

• Predexing

  Podczas generowania pliku biblioteki JACK, .dex biblioteki jest generowany i zapisywany w pliku biblioteki .jack jako pre-dex. Podczas kompilacji JACK ponownie wykorzystuje pre-dex z każdej biblioteki. Wszystkie biblioteki są wstępnie zdefiniowane.

• Kompilacja przyrostowa

  Kompilacja przyrostowa oznacza, że ​​rekompilowane są tylko składniki, które zostały dotknięte od czasu ostatniej kompilacji, oraz ich zależności. Kompilacja przyrostowa może być znacznie szybsza niż kompilacja pełna, gdy zmiany są ograniczone tylko do ograniczonego zestawu składników.

• Przepakowywanie

  JACK używa plików konfiguracyjnych jarjar do ponownego pakowania.

• Wsparcie Multidex

  Ponieważ pliki dex są ograniczone do metod 65K, aplikacje z metodami ponad 65K muszą być podzielone na wiele plików dex. (Aby uzyskać więcej informacji o multidex, zobacz „Tworzenie aplikacji przy użyciu ponad 65 000 metod”).

Niedogodności:

• Transform API nie jest obsługiwane przez Jacka - nie ma pośredniego kodu bajtowego Javy, który można zmodyfikować, więc niektóre wtyczki, o których tutaj nie wspomniałem, przestaną działać
• Przetwarzanie adnotacji nie jest obecnie obsługiwane przez Jacka, więc jeśli w dużym stopniu polegasz na bibliotekach, takich jak Dagger, AutoValue itp., Powinieneś dobrze się zastanowić przed przejściem na Jacka. EDYCJA: Jak zauważył Jake Wharton, Jack w N Preview obsługuje przetwarzanie adnotacji, ale nie jest jeszcze ujawniany przez Gradle.
• Detektory kłaczków działające na poziomie kodu bajtowego Java nie są obsługiwane.
• Jacoco nie jest obsługiwane - cóż, osobiście uważam Jacoco za wątpliwe (tak naprawdę nie pokazuje tego, co chcesz zobaczyć), więc mogę całkowicie bez niego żyć
• Dexguard - wersja Enterprise Proguard nie jest obecnie obsługiwana

Google nie zamierza wypychać Jacka jako domyślnego narzędzia, ale Jack and Jill.
Kompilowanie plików .class do dex z Jill jest tutaj. W przeciwnym razie możesz pożegnać się z bibliotekami jar / aar.

Czy Jack czy Jill będą wolniejsi, nadal jest przedmiotem dyskusji. Zespół Androida ma nadzieję, że jack będzie szybszy niż obecny proces kompilacji, ale teraz tak nie jest

Co więcej, Jack i Dex są dostępni na otwartej przestrzeni, nic nie stoi na przeszkodzie, aby zespół kotlin napisał narzędzie emitujące pliki .jack lub .dex z kodu źródłowego kotlin.

UPDATE (16.03.2017)

Na szczęście Jack nie żyje, więc nie wpłynie to na programistów Kotlin.

Jeśli Jack jest przyszłością, utkniesz w przeszłości z Kotlinem. Obecnie Jack nie obsługuje wtyczek, które mogą kompilować źródła inne niż Java do kodu bajtowego Dalvik. A nawet gdyby tak było, JetBrains musiałby dodać nowy backend do kompilatora Kotlin, co nie jest łatwym zadaniem. Będziesz więc musiał używać Kotlina z Jill i będzie to coś bardzo podobnego do łańcucha narzędzi, którego używasz teraz.

Jak widać na poniższym obrazku, nawet jeśli nie można jawnie wyłączyć Jacka, nadal będziesz mógł przekonwertować projekt na projekt biblioteki, aby używać Jill. Projekt aplikacji będzie po prostu odnosił się do tego projektu biblioteki.

Jedynym sposobem, w jaki widzę, jak Kotlin może współpracować z Jackiem, który prawdopodobnie nie zostanie zaimplementowany, jest dodanie zaplecza Java do kompilatora Kotlin, czyli zaplecza, które generuje kod Javy taki jak Xtend . W takim przypadku kod wygenerowany przez kompilator Kotlin może być przetwarzany przez Jacka jak każdy inny kod Java.

Ale w tej chwili nie wiemy dokładnie, co Jack będzie wspierać, kiedy zostanie wydany. Może coś się diametralnie zmieni i dodanie obsługi Kotlina do Jacka stanie się możliwe.

Jak wspomniano w poście na blogu ( mapa drogowa systemu Android Kotlin ), który pojawił się dzisiaj:

W tej chwili istnieją pewne problemy, które uniemożliwiają Jackowi poprawną obsługę kodu bajtowego wygenerowanego przez Kotlina ( 196084 i 203531 ), ale planujemy współpracować z zespołem Google w celu rozwiązania problemów lub zapewnienia obejścia po naszej stronie. Gdy to zrobisz, będziemy mogli tłumaczyć tylko zmienione pliki klas przy użyciu Jill podczas kompilacji przyrostowej, w przeciwieństwie do tłumaczenia wszystkich plików klas za każdym razem (co jest jedynym możliwym zachowaniem w starym narzędziu Android).

Więc Kotlin ostatecznie wesprze Jack & Jill i odniesie z tego korzyści.

Zgodnie z najnowszym ogłoszeniem Google -

Zdecydowaliśmy się dodać obsługę funkcji języka Java 8 bezpośrednio do bieżącego zestawu narzędzi javac i dx oraz wycofać łańcuch narzędzi Jacka. W tym nowym kierunku istniejące narzędzia i wtyczki zależne od formatu plików klas Java powinny nadal działać. W przyszłości funkcje języka Java 8 będą natywnie obsługiwane przez system kompilacji Androida. Zamierzamy uruchomić to w ramach Android Studio w nadchodzących tygodniach i chcieliśmy podzielić się z wami tą decyzją na wczesnym etapie.

Początkowo testowaliśmy dodanie obsługi Java 8 za pośrednictwem łańcucha narzędzi Jack. Z biegiem czasu zdaliśmy sobie sprawę, że koszt przejścia na Jacka był zbyt wysoki dla naszej społeczności, gdy wzięliśmy pod uwagę wpływ procesorów adnotacji, analizatorów kodu bajtowego i korektorów. Dziękujemy za wypróbowanie łańcucha narzędzi Jack i przekazanie nam wspaniałych opinii. Możesz nadal używać Jacka do tworzenia kodu Java 8, dopóki nie udostępnimy nowej obsługi. Migracja z Jacka powinna wymagać niewielkiej lub żadnej pracy.

Nie musimy więc martwić się, że łańcuch narzędzi jack stanie się domyślnym łańcuchem narzędzi do tworzenia aplikacji na Androida. Możesz nadal używać kotlin lub normalnego zestawu narzędzi javac / dx.

Źródło: Przyszłość obsługi funkcji językowych Java 8 w systemie Android

Znalazłem już ten wpis na oficjalnym blogu Kotlina :: Mapa drogowa Kotlina na Androida

Tam znajdziesz część, która mówi, że:

Następną rzeczą, którą planujemy zrobić, aby poprawić wydajność kompilacji Androida, jest zapewnienie integracji z nowym łańcuchem narzędzi Jack and Jill Androida . W tej chwili istnieją pewne problemy, które uniemożliwiają Jackowi poprawną obsługę kodu bajtowego wygenerowanego przez Kotlina ( 196084 i 203531 ), ale planujemy współpracować z zespołem Google w celu rozwiązania problemów lub zapewnienia obejścia po naszej stronie. Gdy to zrobisz, będziemy mogli tłumaczyć tylko zmienione pliki klas przy użyciu Jill podczas kompilacji przyrostowej, w przeciwieństwie do tłumaczenia wszystkich plików klas za każdym razem (co jest jedynym możliwym zachowaniem w starym narzędziu Android).

Więc jak powiedział @LukasBergstrom, nie będzie żadnego problemu z „utknięciem w przeszłości” ;-)

Możesz również sprawdzić Redditdyskusję związaną z tym tematem: Jaki jest status Kotlina z Jackiem i Jill?

Miłego kodowania.

Według bloga Kotlin , sekcja Nowe funkcje w wersji 1.1-beta2:

Wsparcie dla budowania projektów Android, gdy włączony jest łańcuch narzędzi Jacka (jackOptions {true});