Android N Java 8 características (Jack compilador) y Kotlin interoperabilidad

Responsabilidad: trabajo en Jack

Esto no le afectará. El compilador de Kotlin produce Java 6 bytecode, que Jack / Jill puede importar muy bien.

@Pavel Dudka

Jack – es un compilador. Similar a javac, pero hace algo ligeramente diferente:

Como se puede ver, Jack compila código fuente Java directamente en el archivo Dex! Ya no tenemos archivos intermedios * .class, por lo que no se necesita herramienta dx!

¡Pero espera! ¿Qué pasa si incluyo una biblioteca de terceros en mi proyecto (que viene como una colección de archivos .class)?

Y ahí es cuando Jill entra en juego:

Jill puede procesar los archivos de clase y transformarlos en un formato Jayce especial que se puede utilizar como una entrada para el compilador Jack.

Así que ahora vamos a dar un paso por un segundo y pensar … ¿Qué va a pasar con todos esos plugins cool que nos hicieron tan adictos? Todos ellos necesitan archivos .class y el compilador Jack no los tiene más …

Por suerte, Jack ofrece algunas de las características importantes para nosotros fuera de la caja:

• Retrolambda – no será necesario. Jack puede manejar lambdas correctamente
• Proguard – se cuece en Jack ahora, por lo que todavía puede utilizar obfuscation y minimización

Ventajas:

Jack soporta el lenguaje de programación Java 1.7 e integra funciones adicionales descritas a continuación.

• Predexing

  Al generar un archivo de biblioteca JACK, el .dex de la biblioteca se genera y se almacena dentro del archivo de biblioteca .jack como predex. Al compilar, JACK reutiliza el pre-dex de cada biblioteca. Todas las bibliotecas están predexadas.

• Recopilación incremental

  La compilación incremental significa que sólo se recompilan los componentes que se tocaron desde la última compilación y sus dependencias. La compilación incremental puede ser significativamente más rápida que una compilación completa cuando los cambios se limitan a un conjunto limitado de componentes.

• Reacondicionamiento

  JACK utiliza archivos de configuración jarjar para realizar el reempaquetado.

• Soporte multidex

  Dado que los archivos dex están limitados a métodos de 65K, las aplicaciones con más de 65K métodos deben dividirse en múltiples archivos dex. (Consulte "Creación de aplicaciones con más de 65K Métodos" para obtener más información acerca de multidex.)

Desventajas:

• La API de transformación no es compatible con Jack – no hay ningún bytecode intermedio de Java que puedas modificar, por lo que algunos complementos que no mencione aquí dejarán de funcionar
• El procesamiento de anotaciones no está actualmente soportado por Jack, así que si depende mucho de bibliotecas como Dagger, AutoValue, etc., debe pensar dos veces antes de cambiar a Jack. EDIT: Como se ha señalado por Jake Wharton, Jack in N Preview tiene soporte de procesamiento de anotaciones, pero no está expuesto aún a través de Gradle.
• Los detectores de pelusa que operan en un nivel de bytecode Java no son compatibles.
• Jacoco no es compatible – bueno, personalmente encuentro a Jacoco cuestionable (no muestra realmente lo que quieres ver), así que puede vivir totalmente sin él
• Dexguard: la versión de empresa de Proguard no se admite actualmente

Google no va a presionar a Jack como la herramienta predeterminada, sino a Jack and Jill .
Compilar archivos .class para dex con Jill está aquí para quedarse. De lo contrario, puede decir adiós a las bibliotecas jar / aar.

Si Jack o Jill serán más lentos todavía está pendiente de debate. El equipo de Android espera que Jack sea más rápido que el proceso de creación actual, pero eso no es el caso ahora

Además, Jack y Dex están disponibles al aire libre, nada impide que el equipo de kotlin escriba una herramienta que emite archivos .jack o .dex de kotlin sourcecode.

ACTUALIZACIÓN (16/03/2017)

Por suerte, Jack está muerto y por lo tanto no afectará a los desarrolladores de Kotlin.

Si Jack es el futuro, entonces te quedarás atrapado en el pasado con Kotlin. Actualmente, Jack no admite plugins que puedan compilar fuentes no Java en el bytecode de Dalvik. E incluso si lo hiciera JetBrains necesitaría agregar un nuevo backend al compilador de Kotlin que no es una tarea trivial. Así que tendrá que usar Kotlin con Jill y va a ser algo muy similar a la cadena de herramientas que utiliza ahora.

Como se puede ver en la imagen a continuación, incluso si es imposible desactivar explícitamente Jack que todavía será capaz de convertir el proyecto en un proyecto de biblioteca para utilizar Jill. Y el proyecto de la aplicación sólo hará referencia a este proyecto de biblioteca.

La única manera de ver cómo Kotlin puede trabajar con Jack, que probablemente no se implementará, es añadir un backend Java al compilador de Kotlin, es decir, un backend que genera código Java como Xtend . En este caso, el código generado por el compilador Kotlin puede ser procesado por Jack como cualquier otro código Java.

Pero por el momento no sabemos exactamente lo que Jack apoyará cuando sea lanzado. Tal vez algo va a cambiar dramáticamente y añadir el apoyo de Kotlin a Jack será posible.

Como se dijo en el blog ( Kotlin's Android Roadmap ) que apareció hoy:

En estos momentos hay algunos problemas que impiden que Jack maneje el bytecode generado por Kotlin correctamente ( 196084 y 203531 ), pero planeamos trabajar con el equipo de Google para resolver los problemas o proporcionar soluciones a nuestro lado. Una vez hecho esto, podremos traducir solo los archivos de clase cambiados usando Jill durante la compilación incremental, en lugar de traducir todos los archivos de clase cada vez (que es el único comportamiento posible en la vieja herramienta de Android).

Así que Kotlin eventualmente apoyará a Jack y Jill y obtendrá beneficios de ella.

Ya he encontrado esta entrada en el blog oficial de Kotlin: Kotlin's Android Roadmap

Allí encontrarías una parte que dice que:

Lo siguiente que planeamos hacer para mejorar el rendimiento de la compilación de Android es proporcionar una integración con la nueva cadena de herramientas de Android y Jill . En estos momentos hay algunos problemas que impiden que Jack maneje el bytecode generado por Kotlin correctamente ( 196084 y 203531 ), pero planeamos trabajar con el equipo de Google para resolver los problemas o proporcionar soluciones a nuestro lado. Una vez hecho esto, podremos traducir solo los archivos de clase cambiados usando Jill durante la compilación incremental, en lugar de traducir todos los archivos de clase cada vez (que es el único comportamiento posible en la vieja herramienta de Android).

Así como @ LukasBergstrom dijo, no habrá ningún problema con "stucking en el pasado" 😉

También puede consultar la discusión de Reddit relacionada con este tema: ¿Cuál es el estado de Kotlin con Jack y Jill?

Codificación feliz.

Según el último anuncio de google –

Hemos decidido agregar compatibilidad para las características del lenguaje Java 8 directamente en el conjunto actual de herramientas de javac y dx y despreciar la cadena de herramientas Jack. Con esta nueva dirección, las herramientas y complementos existentes dependientes del formato de archivo de la clase Java deben seguir funcionando. Avanzando, las características del lenguaje Java 8 serán compatibles de forma nativa con el sistema de compilación de Android. Tenemos el objetivo de lanzar esto como parte de Android Studio en las próximas semanas, y queríamos compartir esta decisión con usted temprano.

Inicialmente probamos la adición de soporte de Java 8 a través de la cadena de herramientas Jack. Con el tiempo, nos dimos cuenta de que el costo de cambiar a Jack era demasiado alto para nuestra comunidad cuando consideramos los procesadores de anotación, los analizadores de bytecode y los reescritores impactados. Gracias por probar la cadena de herramientas Jack y darnos una gran retroalimentación. Puede continuar usando Jack para construir su código Java 8 hasta que liberemos el nuevo soporte. La migración de Jack debe requerir poco o ningún trabajo.

Por lo tanto, no tenemos que preocuparnos de que jackchain toolchain se convierta en toolchain por defecto para el desarrollo de android. Puede continuar usando kotlin o usar un conjunto normal de herramientas javac / dx.

Fuente: Futuro de Java 8 Feature Feature Feature en Android

Según el blog de Kotlin , la versión 1.1-beta2 Nueva sección de características:

Soporte para la construcción de proyectos de Android cuando la herramienta Jack esté habilitada (jackOptions {true});