tutorial programacion para español desde curso cero java android kotlin android-jack-and-jill

programacion - Características de Android N Java 8(compilador Jack) e interoperabilidad Kotlin



kotlin tutorial español pdf (8)

Actualización 3. KOTLIN AHORA ESTÁ OFICIALMENTE APOYADO PARA EL DESARROLLO DE ANDROID . POR GOOGLE YAAAAAAAAS!

Actualización 2 : Parece que JetBrains está realmente comprometido a admitir Kotlin para Android a largo plazo . Soy un usuario feliz de kotlin :).

Actualización : Hadi Hariri, de JetBrains, mencionó que van a publicar información sobre este tema . Actualizaré esta publicación una vez que lo hagan.


=== MATERIA DEPRECADA SIGUIENTE ===

Google acaba de lanzar una vista previa para el próximo Android N con algunas características interesantes, la más notable es la compatibilidad parcial con el lenguaje Java 8 . Esto es posible debido a la nueva cadena de herramientas Jack en la que Google está trabajando.

La cadena de herramientas actual que usa javac o kotlinc :
javac ( .java -> .class ) -> dx ( .class -> .dex )
kotlinc ( .kt -> .class ) -> dx ( .class -> .dex )

Nueva cadena de herramientas Jack:
Jack ( .java -> .jack -> .dex )

Supongo que Google avanzará para convertir a Jack en la cadena de herramientas predeterminada para el desarrollo de Android. Actualización: Jack ahora está en deprecated . Yas

Mi pregunta es ¿cómo me afectará esta nueva cadena de herramientas, en el futuro, como usuario de kotlin para el desarrollo de Android? ¿Me quedaré "atrapado en el pasado"?

Como se dijo en la publicación del blog ( Kotlin''s Android Roadmap ) que apareció hoy:

En este momento hay algunos problemas que impiden que Jack maneje correctamente el code.google.com/p/android/issues/detail?id=196084 203531 generado por Kotlin ( code.google.com/p/android/issues/detail?id=196084 y 203531 ), pero planeamos trabajar junto con el equipo de Google para resolver los problemas o proporcionar soluciones alternativas de nuestro lado. Una vez hecho esto, podremos traducir solo los archivos de clase modificados utilizando Jill durante la compilación incremental, en lugar de traducir todos los archivos de clase cada vez (que es el único comportamiento posible en las antiguas herramientas de Android).

Entonces Kotlin eventualmente apoyará a Jack & Jill y obtendrá beneficios de ello.

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 aún está en debate. El equipo de Android espera que Jack sea más rápido que el proceso de compilación actual, pero ese no es el caso en este momento

Además, Jack y Dex están disponibles a la intemperie, nada impide que el equipo de Kotlin escriba una herramienta que emita archivos .jack o .dex del código fuente de Kotlin.

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

Soporte para crear proyectos de Android cuando Jack toolchain está habilitado (jackOptions {true});

Según el último anuncio de Google:

Decidimos agregar soporte para las características del lenguaje Java 8 directamente en el conjunto actual de herramientas javac y dx, y desaprobar la cadena de herramientas Jack. Con esta nueva dirección, las herramientas y complementos existentes que dependen del formato de archivo de clase Java deberían continuar funcionando. En el futuro, las características del lenguaje Java 8 serán compatibles de forma nativa con el sistema de compilación de Android. Nuestro objetivo es lanzar esto como parte de Android Studio en las próximas semanas, y queríamos compartir esta decisión temprano con usted.

Inicialmente probamos agregar compatibilidad con 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 anotaciones, analizadores de código de bytes y reescritores afectados. Gracias por probar la cadena de herramientas Jack y por brindarnos excelentes comentarios. Puede continuar usando Jack para construir su código Java 8 hasta que lancemos el nuevo soporte. Migrar desde Jack debería requerir poco o ningún trabajo.

Por lo tanto, no debemos preocuparnos de que Jack Toolchain se convierta en la cadena de herramientas predeterminada para el desarrollo de Android. Puede continuar usando kotlin o usar el conjunto normal de herramientas javac / dx.

Fuente: deprecated

Ya encontré esta publicación de blog del blog oficial de Kotlin:: Kotlin''s Android Roadmap

Allí encontrarás una parte que dice que:

Lo siguiente que planeamos hacer para mejorar el rendimiento de compilación de Android es proporcionar una integración con la nueva cadena de herramientas Jack and Jill de Android. En este momento hay algunos problemas que impiden que Jack maneje correctamente el code.google.com/p/android/issues/detail?id=196084 203531 generado por Kotlin ( code.google.com/p/android/issues/detail?id=196084 y 203531 ), pero planeamos trabajar junto con el equipo de Google para resolver los problemas o proporcionar soluciones alternativas de nuestro lado. Una vez hecho esto, podremos traducir solo los archivos de clase modificados utilizando Jill durante la compilación incremental, en lugar de traducir todos los archivos de clase cada vez (que es el único comportamiento posible en las antiguas herramientas de Android).

Entonces, como dijo @LukasBergstrom, no habrá ningún problema con "pegarse 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?

Feliz codificación

descargo de responsabilidad: yo trabajo en Jack

Esto no te afectará. El compilador de Kotlin produce el código de bytes Java 6, que Jack / Jill puede importar muy bien.

@Pavel Dudka

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

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

¡Pero espera! ¿Qué sucede 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 archivos de clase y transformarlos en un formato especial de Jayce que puede usarse como entrada para el compilador de Jack.

Así que ahora vamos a un lado y pensemos ... ¿Qué va a pasar con todos esos complementos geniales a los que nos volvimos tan adictos? Todos necesitan archivos .class y el compilador Jack ya no los tiene ...

Afortunadamente, Jack proporciona algunas de esas características importantes para nosotros de fábrica:

  • Retrolambda: no será necesario. Jack puede manejar las lambdas adecuadamente
  • Proguard: ahora está integrado en Jack, por lo que aún puede usar la ofuscación y la minimización

Ventajas:

Jack admite el lenguaje de programación Java 1.7 e integra las características adicionales que se describen a continuación.

  • Predexing

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

  • Compilación incremental

    La compilación incremental significa que solo se vuelven a compilar 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.

  • Reempaquetado

    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 deben dividirse en múltiples archivos dex. (Consulte ''Creación de aplicaciones con más de 65,000 métodos'' para obtener más información sobre multidex).

Desventajas

  • Transform API no es compatible con Jack: no hay un código de bytes intermedio de Java que pueda modificar, por lo que algunos complementos que no mencioné aquí dejarán de funcionar
  • Actualmente, Jack no admite el procesamiento de anotaciones, por lo que si depende en gran medida de bibliotecas como Dagger, AutoValue, etc., debe pensarlo dos veces antes de cambiar a Jack. EDITAR: Como señaló Jake Wharton, Jack in N Preview tiene soporte para el procesamiento de anotaciones, pero aún no está expuesto a través de Gradle.
  • Los detectores de pelusa que operan en un nivel de bytecode de Java no son compatibles.
  • Jacoco no es compatible, bueno, personalmente considero que Jacoco es cuestionable (realmente no muestra lo que quieres ver), así que puedo vivir totalmente sin él
  • Dexguard: la versión empresarial de Proguard no es compatible actualmente

ACTUALIZACIÓN (16/03/2017)

Afortunadamente, Jack está muerto y 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 complementos que puedan compilar fuentes que no sean Java en el código de bytes de Dalvik. E incluso si lo hiciera, JetBrains necesitaría agregar un nuevo backend al compilador de Kotlin, lo cual no es una tarea trivial. Entonces tendrá que usar Kotlin con Jill y será algo muy similar a la cadena de herramientas que usa ahora.

Como puede ver en la imagen a continuación, incluso si es imposible desactivar explícitamente Jack, aún podrá convertir el proyecto en un proyecto de biblioteca para usar Jill. Y el proyecto de aplicación solo hará referencia a este proyecto de biblioteca.

La única forma en que veo cómo Kotlin puede trabajar con Jack, que probablemente no se implementará, es agregando un backend de 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 qué soportará Jack cuando se lance. Tal vez algo cambie drásticamente y sea posible agregar soporte de Kotlin a Jack.