Funzionalità Android N Java 8 (compilatore Jack) e interoperabilità Kotlin

Aggiornamento 3. KOTLIN È ORA SUPPORTATO UFFICIALMENTE PER LO SVILUPPO ANDROID . DI GOOGLE. YAAAAAAAAS!

Aggiornamento 2 : sembra che JetBrains sia davvero impegnato a supportare Kotlin per Android a lungo termine . Sono un utente felice di kotlin :).

Aggiornamento : Hadi Hariri, di JetBrains, ha detto che rilasceranno alcune informazioni su questo argomento . Aggiornerò questo post una volta che lo faranno.

=== MATERIALE DEPRECATO SUCCESSIVO ===

Google ha appena rilasciato un'anteprima per il prossimo Android N con alcune caratteristiche interessanti, la più notevole è il supporto parziale del linguaggio Java 8 . Ciò è possibile grazie alla nuova toolchain di Jack su cui Google sta lavorando.

L'attuale toolchain che utilizza javac o kotlinc :
javac ( .java-> .class) -> dx ( .class-> .dex)
kotlinc ( .kt-> .class) -> dx ( .class-> .dex)

Nuova toolchain di Jack:
Jack ( .java-> .jack-> .dex)

Presumo che Google spingerà in avanti per rendere Jack la toolchain predefinita per lo sviluppo Android. Aggiornamento: Jack è ora deprecato . Sì.

La mia domanda è: in che modo questa nuova toolchain influirà su di me, in futuro, come utente kotlin per lo sviluppo Android? Resterò "bloccato nel passato"?

disclaimer: lavoro su Jack

Questo non ti influenzerà. Il compilatore di Kotlin produce bytecode Java 6, che Jack / Jill può importare senza problemi.

@Pavel Dudka

Jack - è un compilatore. Simile a javac, ma fa una cosa leggermente diversa:

Come puoi vedere, Jack compila il codice sorgente Java direttamente nel file Dex! Non abbiamo più file * .class intermedi, quindi lo strumento dx non è necessario!

Ma aspetta! Cosa succede se includo una libreria di terze parti nel mio progetto (che si presenta come una raccolta di file .class)?

Ed è qui che entra in gioco Jill:

Jill può elaborare file di classe e trasformarli in uno speciale formato Jayce che può essere utilizzato come input per il compilatore Jack.

Quindi ora facciamo un passo da parte per un secondo e pensiamo ... cosa succederà a tutti quei fantastici plugin da cui siamo così dipendenti? Hanno tutti bisogno di file .class e il compilatore Jack non li ha più ...

Fortunatamente, Jack fornisce alcune di quelle funzionalità importanti per noi fuori dagli schemi:

• Retrolambda - non sarà necessario. Jack sa gestire correttamente le lambda
• Proguard: ora è integrato in Jack, quindi puoi ancora utilizzare l'offuscamento e la minimizzazione

Vantaggi:

Jack supporta il linguaggio di programmazione Java 1.7 e integra funzionalità aggiuntive descritte di seguito.

• Predexing

  Quando si genera un file di libreria JACK, il .dex della libreria viene generato e memorizzato all'interno del file di libreria .jack come pre-dex. Durante la compilazione, JACK riutilizza il pre-dex di ciascuna libreria. Tutte le librerie sono pre-dexed.

• Compilazione incrementale

  La compilazione incrementale significa che vengono ricompilati solo i componenti che sono stati toccati dall'ultima compilazione e le loro dipendenze. La compilazione incrementale può essere notevolmente più veloce di una compilazione completa quando le modifiche sono limitate a un insieme limitato di componenti.

• Riconfezionamento

  JACK utilizza i file di configurazione jarjar per eseguire il repackaging.

• Supporto multidex

  Poiché i file dex sono limitati a metodi 65K, le app con metodi superiori a 65K devono essere suddivise in più file dex. (Per ulteriori informazioni sul multidex, vedere "Creazione di app con metodi superiori a 65.000".)

Svantaggi:

• L'API Transform non è supportata da Jack: non esiste un bytecode Java intermedio che puoi modificare, quindi alcuni plugin che non ho menzionato qui smetteranno di funzionare
• L'elaborazione delle annotazioni non è attualmente supportata da Jack, quindi se dipendi fortemente da librerie come Dagger, AutoValue, ecc., Dovresti pensarci due volte prima di passare a Jack. EDIT: come sottolineato da Jake Wharton, Jack in N Preview ha il supporto per l'elaborazione delle annotazioni, ma non è ancora esposto tramite Gradle.
• I rilevatori di lanugine che operano a livello di bytecode Java non sono supportati.
• Jacoco non è supportato - beh, personalmente trovo Jacoco discutibile (non mostra davvero ciò che vuoi vedere), quindi puoi vivere totalmente senza di esso
• Dexguard: la versione enterprise di Proguard non è attualmente supportata

Google non ha intenzione di spingere Jack come strumento predefinito, ma Jack and Jill.
La compilazione di file .class in dex con Jill è qui per restare. Altrimenti, puoi dire addio alle librerie jar / aar.

Se Jack o Jill saranno più lenti è ancora oggetto di discussione. Il team di Android spera che Jack sia più veloce dell'attuale processo di build, ma al momento non è così

Inoltre, Jack e Dex sono disponibili allo scoperto, nulla impedisce al team di kotlin di scrivere uno strumento che emette file .jack o .dex dal codice sorgente di kotlin.

AGGIORNAMENTO (16/03/2017)

Fortunatamente, Jack è morto e quindi non influenzerà gli sviluppatori di Kotlin.

Se Jack è il futuro, rimarrai bloccato nel passato con Kotlin. Attualmente Jack non supporta plugin che possono compilare sorgenti non Java in bytecode Dalvik. E anche se lo facesse, JetBrains avrebbe bisogno di aggiungere un nuovo backend al compilatore Kotlin, il che non è un compito banale. Quindi dovrai usare Kotlin con Jill e sarà qualcosa di molto simile alla toolchain che usi ora.

Come puoi vedere nell'immagine qui sotto, anche se è impossibile disattivare esplicitamente Jack, sarai comunque in grado di convertire il progetto in un progetto di libreria per utilizzare Jill. E il progetto dell'applicazione farà riferimento solo a questo progetto di libreria.

L'unico modo in cui vedo come Kotlin possa lavorare con Jack, che probabilmente non verrà implementato, è aggiungere un backend Java al compilatore Kotlin, cioè un backend che genera codice Java come Xtend . In questo caso il codice generato dal compilatore Kotlin può essere elaborato da Jack come qualsiasi altro codice Java.

Ma al momento non sappiamo esattamente cosa supporterà Jack quando uscirà. Forse qualcosa cambierà drasticamente e sarà possibile aggiungere il supporto Kotlin a Jack.

Come detto nel post del blog ( Kotlin's Android Roadmap ) apparso oggi:

Al momento ci sono alcuni problemi che impediscono a Jack di gestire correttamente il bytecode generato da Kotlin ( 196084 e 203531 ), ma abbiamo in programma di collaborare con il team di Google per risolvere i problemi o fornire soluzioni alternative dalla nostra parte. Una volta fatto questo, saremo in grado di tradurre solo i file di classe modificati usando Jill durante la compilazione incrementale, invece di tradurre tutti i file di classe ogni volta (che è l'unico comportamento possibile nei vecchi strumenti Android).

Quindi Kotlin alla fine supporterà Jack & Jill e ne trarrà dei benefici.

Come da ultimo annuncio di Google -

Abbiamo deciso di aggiungere il supporto per le funzionalità del linguaggio Java 8 direttamente nell'attuale set di strumenti javac e dx e deprecare la toolchain di Jack. Con questa nuova direzione, gli strumenti e i plug-in esistenti dipendenti dal formato del file di classe Java dovrebbero continuare a funzionare. Andando avanti, le funzionalità del linguaggio Java 8 saranno supportate nativamente dal sistema di build Android. Puntiamo a lanciarlo come parte di Android Studio nelle prossime settimane e volevamo condividere questa decisione con te in anticipo.

Inizialmente abbiamo testato l'aggiunta del supporto Java 8 tramite la toolchain di Jack. Nel tempo, ci siamo resi conto che il costo del passaggio a Jack era troppo alto per la nostra comunità quando abbiamo considerato i processori di annotazione, gli analizzatori di bytecode ei riscrittori interessati. Grazie per aver provato la toolchain di Jack e per averci fornito un ottimo feedback. Puoi continuare a utilizzare Jack per creare il tuo codice Java 8 fino al rilascio del nuovo supporto. La migrazione da Jack dovrebbe richiedere poco o nessun lavoro.

Quindi non dobbiamo preoccuparci che jack toolchain diventi toolchain predefinito per lo sviluppo Android. È possibile continuare a utilizzare kotlin o utilizzare il normale set di strumenti javac / dx.

Fonte: supporto della funzionalità Future of Java 8 Language su Android

Ho già trovato questo post del blog dal blog ufficiale di Kotlin:: Kotlin's Android Roadmap

Lì troverai una parte che dice che:

La prossima cosa che abbiamo in programma di fare per migliorare le prestazioni di build Android è fornire un'integrazione con la nuova toolchain di Android Jack and Jill . Al momento ci sono alcuni problemi che impediscono a Jack di gestire correttamente il bytecode generato da Kotlin ( 196084 e 203531 ), ma abbiamo in programma di collaborare con il team di Google per risolvere i problemi o fornire soluzioni alternative dalla nostra parte. Una volta fatto questo, saremo in grado di tradurre solo i file di classe modificati utilizzando Jill durante la compilazione incrementale, invece di tradurre tutti i file di classe ogni volta (che è l'unico comportamento possibile nei vecchi strumenti Android).

Quindi, come ha detto @LukasBergstrom, non ci saranno problemi con "rimanere bloccati nel passato" ;-)

Puoi anche controllare la Redditdiscussione collegata a questo argomento: Qual è lo stato di Kotlin con Jack e Jill?

Buona codifica.

Secondo il blog di Kotlin , versione 1.1-beta2 della sezione Nuove funzionalità:

Supporto per la creazione di progetti Android quando la toolchain Jack è abilitata (jackOptions {true});