Recursos do Android N Java 8 (compilador Jack) e interoperabilidade Kotlin

Atualização 3. O KOTLIN AGORA É OFICIALMENTE SUPORTADO PARA O DESENVOLVIMENTO ANDROID . POR GOOGLE. YAAAAAAAAS!

Atualização 2 : Parece que a JetBrains está realmente comprometida em oferecer suporte ao Kotlin para Android a longo prazo . Sou um usuário feliz do kotlin :).

Atualização : Hadi Hariri, da JetBrains, mencionou que vai lançar algumas informações sobre este assunto . Vou atualizar este post assim que eles fizerem.

=== MATERIAL DESCONTINUADO PRÓXIMO ===

O Google acaba de lançar uma prévia do Android N com alguns recursos interessantes, sendo o mais notável o suporte parcial à linguagem Java 8 . Isso é possível devido ao novo conjunto de ferramentas Jack no qual o Google está trabalhando.

O conjunto de ferramentas atual usando javac ou kotlinc :
javac ( .java-> .class) -> dx ( .class-> .dex)
kotlinc ( .kt-> .class) -> dx ( .class-> .dex)

Novo conjunto de ferramentas Jack:
Jack ( .java-> .jack-> .dex)

Estou assumindo que o Google avançará no sentido de tornar o Jack o conjunto de ferramentas padrão para o desenvolvimento do Android. Atualização: Jack agora está obsoleto . Sim.

Minha pergunta é como esse novo conjunto de ferramentas me afetará, no futuro, como um usuário kotlin para desenvolvimento Android? Ficarei "preso ao passado"?

isenção de responsabilidade: eu trabalho no Jack

Isso não afetará você. O compilador de Kotlin produz bytecode Java 6, que Jack / Jill pode importar perfeitamente.

@Pavel Dudka

Jack - é um compilador. Semelhante ao javac, mas faz uma coisa um pouco diferente:

Como você pode ver, Jack compila o código-fonte Java diretamente no arquivo Dex! Não temos mais arquivos * .class intermediários, então a ferramenta dx não é necessária!

Mas espere! E se eu incluir uma biblioteca de terceiros em meu projeto (que vem como uma coleção de arquivos .class)?

E é aí que Jill entra em jogo:

Jill pode processar arquivos de classe e transformá-los em um formato Jayce especial que pode ser usado como entrada para o compilador Jack.

Então, agora vamos dar um passo de lado por um segundo e pensar ... O que vai acontecer com todos aqueles plugins legais nos quais ficamos tão viciados? Todos eles precisam de arquivos .class e o compilador Jack não os tem mais ...

Felizmente, Jack fornece alguns desses recursos importantes para nós prontos para uso:

• Retrolambda - não será necessário. Jack pode lidar com lambdas corretamente
• Proguard - agora está embutido no Jack, então você ainda pode usar ofuscação e minimização

Vantagens:

Jack oferece suporte à linguagem de programação Java 1.7 e integra recursos adicionais descritos abaixo.

• Predexing

  Ao gerar um arquivo de biblioteca JACK, o .dex da biblioteca é gerado e armazenado dentro do arquivo de biblioteca .jack como um pré-dex. Ao compilar, JACK reutiliza o pré-dex de cada biblioteca. Todas as bibliotecas são pré-dexadas.

• Compilação incremental

  Compilação incremental significa que apenas os componentes que foram tocados desde a última compilação e suas dependências são recompilados. A compilação incremental pode ser significativamente mais rápida do que uma compilação completa quando as alterações são limitadas a apenas um conjunto limitado de componentes.

• Reembalagem

  JACK usa arquivos de configuração jarjar para fazer o reempacotamento.

• Suporte Multidex

  Como os arquivos dex são limitados a métodos de 65K, os aplicativos com métodos de mais de 65K devem ser divididos em vários arquivos dex. (Consulte 'Criando aplicativos com mais de 65 mil métodos' para obter mais informações sobre multidex.)

Desvantagens:

• A API de transformação não é suportada pelo Jack - não há bytecode Java intermediário que você possa modificar, então alguns plug-ins que não mencionei aqui irão parar de funcionar
• O processamento de anotações não é suportado atualmente pelo Jack, então se você depende muito de bibliotecas como Dagger, AutoValue, etc., você deve pensar duas vezes antes de mudar para o Jack. EDIT: Como apontado por Jake Wharton, Jack in N Preview tem suporte para processamento de anotação, mas ainda não foi exposto por meio do Gradle.
• Os detectores de lint que operam em um nível de bytecode Java não são suportados.
• Jacoco não é suportado - bem, eu pessoalmente acho o Jacoco questionável (ele realmente não mostra o que você quer ver), então posso viver totalmente sem ele
• Dexguard - a versão empresarial do Proguard não é atualmente suportada

O Google não vai colocar o Jack como a ferramenta padrão, mas Jack and Jill.
Compilar arquivos .class para dex com Jill veio para ficar. Caso contrário, você pode dizer adeus às bibliotecas jar / aar.

Se Jack ou Jill serão mais lentos, ainda está em debate. A equipe do Android espera que o jack seja mais rápido do que o processo de compilação atual, mas esse não é o caso agora

Além disso, Jack e Dex estão disponíveis abertamente, nada impede que a equipe do kotlin escreva uma ferramenta que emita arquivos .jack ou .dex do código fonte do kotlin.

ATUALIZAÇÃO (16/03/2017)

Felizmente, Jack está morto e isso não afetará os desenvolvedores do Kotlin.

Se Jack for o futuro, você ficará preso ao passado com Kotlin. Atualmente, o Jack não oferece suporte a plug-ins que podem compilar fontes não-Java no bytecode Dalvik. E mesmo que fizesse, o JetBrains precisaria adicionar um novo back-end ao compilador Kotlin, o que não é uma tarefa trivial. Portanto, você terá que usar o Kotlin com Jill e será algo muito semelhante ao conjunto de ferramentas que você usa agora.

Como você pode ver na imagem abaixo, mesmo que seja impossível desligar explicitamente o Jack, você ainda poderá converter o projeto em um projeto de biblioteca para usar Jill. E o projeto do aplicativo apenas fará referência a este projeto de biblioteca.

A única maneira de ver como Kotlin pode funcionar com Jack, o que provavelmente não será implementado, é adicionando um back-end Java ao compilador Kotlin, ou seja, um back-end que gera código Java como o Xtend . Nesse caso, o código gerado pelo compilador Kotlin pode ser processado por Jack como qualquer outro código Java.

Mas no momento não sabemos exatamente o que Jack apoiará quando for lançado. Talvez algo mude drasticamente e a adição de suporte Kotlin a Jack se torne possível.

Conforme dito na postagem do blog ( Kotlin's Android Roadmap ) que apareceu hoje:

No momento, existem alguns problemas que impedem Jack de lidar com o bytecode gerado pelo Kotlin corretamente ( 196084 e 203531 ), mas planejamos trabalhar junto com a equipe do Google para resolver os problemas ou fornecer soluções alternativas de nossa parte. Uma vez feito isso , seremos capazes de traduzir apenas os arquivos de classe alterados usando Jill durante a compilação incremental, ao invés de traduzir todos os arquivos de classe todas as vezes (que é o único comportamento possível nas antigas ferramentas do Android).

Portanto, Kotlin acabará apoiando Jack e Jill e obterá benefícios com isso.

De acordo com o último anúncio do Google -

Decidimos adicionar suporte para recursos da linguagem Java 8 diretamente no conjunto de ferramentas javac e dx atual e descontinuar o conjunto de ferramentas Jack. Com essa nova direção, as ferramentas e plug-ins existentes dependentes do formato de arquivo da classe Java devem continuar a funcionar. No futuro, os recursos da linguagem Java 8 terão suporte nativo do sistema de construção do Android. Pretendemos lançar isso como parte do Android Studio nas próximas semanas e gostaríamos de compartilhar essa decisão com você o quanto antes.

Inicialmente testamos a adição de suporte a Java 8 por meio do conjunto de ferramentas Jack. Com o tempo, percebemos que o custo de mudar para Jack era muito alto para nossa comunidade quando consideramos os processadores de anotação, analisadores de bytecode e reescritores afetados. Obrigado por experimentar o conjunto de ferramentas Jack e nos dar ótimos comentários. Você pode continuar usando o Jack para construir seu código Java 8 até lançarmos o novo suporte. Migrar de Jack deve exigir pouco ou nenhum trabalho.

Portanto, não precisamos nos preocupar com o conjunto de ferramentas jack se tornando o conjunto de ferramentas padrão para o desenvolvimento do Android. Você pode continuar a usar o kotlin ou usar o conjunto normal de ferramentas javac / dx.

Fonte: Future of Java 8 Language Feature Support no Android

Já encontrei esta postagem do blog oficial do Kotlin:: Roteiro do Android do Kotlin

Lá você encontrará uma parte que diz que:

A próxima coisa que planejamos fazer para melhorar o desempenho de construção do Android é fornecer uma integração com a nova cadeia de ferramentas Jack e Jill do Android . No momento, existem alguns problemas que impedem Jack de lidar com o bytecode gerado pelo Kotlin corretamente ( 196084 e 203531 ), mas planejamos trabalhar junto com a equipe do Google para resolver os problemas ou fornecer soluções alternativas de nossa parte. Uma vez feito isso, seremos capazes de traduzir apenas os arquivos de classe alterados usando Jill durante a compilação incremental, em vez de traduzir todos os arquivos de classe todas as vezes (que é o único comportamento possível nas ferramentas antigas do Android).

Então, como @LukasBergstrom disse, não haverá nenhum problema em "travar no passado" ;-)

Você também pode verificar a Redditdiscussão relacionada a este tópico: Qual é o status de Kotlin com Jack e Jill?

Boa codificação.

De acordo com o blog do Kotlin , lançamento da seção 1.1-beta2 Novos recursos:

Suporte para construção de projetos Android quando o conjunto de ferramentas Jack está habilitado (jackOptions {true});