Funciones de Android N Java 8 (compilador Jack) e interoperabilidad de Kotlin


98

Actualización 3. KOTLIN TIENE AHORA APOYO OFICIAL PARA EL DESARROLLO DE ANDROID . POR GOOGLE. ¡YAAAAAAAAS!

Actualización 2 : Parece que JetBrains está realmente comprometido con la compatibilidad con 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.


=== COSAS DESAPARECIDAS 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 gracias a la nueva cadena de herramientas Jack en la que está trabajando Google.

La cadena de herramientas actual usando 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 desuso . 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"?


1
(kotlin_library (multiple * .kt) => .jar) luego Jill (.jar => Jayce) luego importar a jack (similar a otros frascos (no android) (java simple))
Selvin

Leyendo los documentos: "No tienes que hacer nada diferente para usar Jack; solo usa tus comandos estándar de makefile para compilar el árbol o tu proyecto. Jack es la cadena de herramientas de construcción predeterminada de Android para M." - fuente: source.android.com/source/jack.html seguramente eso es un error tipográfico y significan 'N' y no 'M' .
Mark Keen

Jack está muerto, regocíjate: P
EpicPandaForce

Respuestas:


63

descargo de responsabilidad: trabajo en Jack

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


7
¿Puedes compartir algunos detalles sobre eso? :)
Tudor Luca

Pero, ¿podrá Kotlin beneficiarse de la optimización del rendimiento de Jack? (al menos un día) porque Jack parece bastante impresionante (no puedo esperar por un punto de referencia en este momento)
NitroG42

He visto una presentación en video de un punto de referencia del autor de proguard, con un poco de búsqueda en Google, podrá encontrarlo
sakis kaliakoudas

Estamos experimentando algunas dificultades con la construcción del proyecto de Android con el stdlib de Kotlin adjunto. Parece un error en Jill / Jack. ¿Podrías investigarlo? code.google.com/p/android/issues/detail?id=196084
yanex

1
¿Significa que Jill no acepta el código de bytes de Java 8? ¿Qué pasa con los módulos de la biblioteca? Si se compilan en .aar y luego Jill los importa, ¿tampoco pueden usar Java 8? Es decir, ¿significa que las nuevas funciones de Java están disponibles solo para fuentes internas .java del proyecto?
far.be

15

@Pavel Dudka

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

ingrese la descripción de la imagen aquí

Como puede ver, Jack compila el código fuente de Java directamente en el archivo Dex. Ya no tenemos archivos * .class intermedios, 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:

ingrese la descripción de la imagen aquí

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

Así que ahora hagamos a un lado por un segundo 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 ofrece algunas de esas funciones importantes para nosotros listas para usar:

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

Ventajas:

Jack es compatible con el lenguaje de programación Java 1.7 e integra funciones adicionales que se describen a continuación.

  • Predexar

    Al generar un archivo de biblioteca JACK, el .dex de la biblioteca se genera y almacena dentro del archivo de biblioteca .jack como pre-dex. Al compilar, JACK reutiliza el prefijo 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.

  • Reembalaje

    JACK usa archivos de configuración jarjar para hacer el reempaquetado.

  • Soporte multidex

    Dado que los archivos dex están limitados a métodos de 65K, las aplicaciones con métodos de más de 65K deben dividirse en varios archivos dex. (Consulte 'Creación de aplicaciones con más de 65.000 métodos' para obtener más información sobre multidex).

Desventajas:

  • Jack no admite la API de transformación; no hay un código de bytes Java intermedio 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 procesamiento de anotaciones, pero aún no está expuesto a través de Gradle.
  • Los detectores de pelusa que operan en un nivel de código de bytes de Java no son compatibles.
  • Jacoco no es compatible, bueno, personalmente encuentro a Jacoco cuestionable (realmente no muestra lo que quieres ver), así que puedo vivir sin él.
  • Dexguard: la versión empresarial de Proguard no es compatible actualmente

¿El "procesamiento de anotaciones actualmente no es compatible con Jack" todavía se mantiene en septiembre de 2016? Parece que ahora es compatible ...
ticofab

es compatible, pero todavía hay errores: por ejemplo, el enlace de datos aún no funciona: consulte android # 210615
TmTron

Tenga en cuenta que el procesamiento de anotaciones NO ES totalmente compatible con Jack; está en el mismo estado decrépito que en Eclipse Compiler, en el que se basa Jack ( varios métodos se implementan como marcadores de posición, que arrojan excepciones cuando se llaman , hay numerosos errores sin corregir, archivados en el rastreador de errores ECJ).
user1643723

7

Google no va a impulsar a Jack como la herramienta predeterminada, pero Jack and Jill.
La compilación de archivos .class a dex con Jill llegó para quedarse. De lo contrario, puede despedirse de las bibliotecas jar / aar.

Si Jack o Jill serán más lentos todavía 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 al aire libre, nada impide que el equipo de kotlin escriba una herramienta que emita archivos .jack o .dex desde el código fuente de kotlin.


7

ACTUALIZACIÓN (16/03/2017)

Afortunadamente, Jack está muerto, por lo que no afectará a los desarrolladores de Kotlin.


Si Jack es el futuro, te quedarás atrapado en el pasado con Kotlin. Actualmente, Jack no admite complementos que puedan compilar fuentes que no sean de 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. Así que tendrás que usar Kotlin con Jill y será algo muy similar a la cadena de herramientas que usas ahora.

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

Compilación de la aplicación Jack and Jill

La única forma en que veo cómo Kotlin puede funcionar 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, Jack puede procesar el código generado por el compilador de Kotlin como cualquier otro código Java.

Pero por el momento no sabemos exactamente qué apoyará Jack cuando se lance. Tal vez algo cambie drásticamente y sea posible agregar soporte de Kotlin a Jack.


7
En realidad, el equipo de Kotlin tiene planes para apoyar a Jack & Jill, me enteré en su evento en vivo, pero prefiero una publicación oficial de JetBrains aquí, así que no respondí la pregunta.
tecla

Eso sería genial, pero el único apoyo del que escuché es a través de Jill. Y como mencioné en la respuesta, no hay tantas formas de agregar este soporte.
Michael

De hecho, había algo sobre la generación de código en memoria (y una opción mucho menos realista, Kotlin -> dex), por lo que la compilación de Kotlin para Android también tendría una aceleración significativa.
tecla

No entiendo cómo la generación de código en memoria se relaciona con la integración de Jack. Y la compilación de Kotlin a dex significa que JetBrains necesita escribir y admitir su propia cadena de herramientas similar a Jack.
Michael

1
No estoy seguro de que nadie que no sea el equipo de Kotlin deba decir lo que pueden y no pueden hacer, o lo que podrían o no hacer. Han hablado de esto antes y tienen planes que pueden presentar.
Jayson Minard

5

Como se dijo en la publicación del blog ( Hoja de ruta de Android de Kotlin ) que apareció hoy:

En este momento, existen algunos problemas que impiden que Jack maneje correctamente el código de bytes generado por Kotlin ( 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 clases modificados utilizando Jill durante la compilación incremental, en lugar de traducir todos los archivos de clases cada vez (que es el único comportamiento posible en las antiguas herramientas de Android).

Entonces, Kotlin eventualmente apoyará a Jack & Jill y se beneficiará de ello.


2

Según el último anuncio de Google:

Hemos decidido 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 la clase Java deberían seguir 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 con usted desde el principio.

Inicialmente probamos la adición de 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, los analizadores de códigos de bytes y los reescritores afectados. Gracias por probar la cadena de herramientas Jack y darnos excelentes comentarios. Puede continuar usando Jack para compilar su código Java 8 hasta que lancemos el nuevo soporte. La migración 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: Compatibilidad con las funciones del lenguaje Future of Java 8 en Android


1

Ya encontré esta publicación del blog oficial de Kotlin:: Hoja de ruta de Android de Kotlin

Allí encontrará 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 Jack y Jill de Android . En este momento, existen algunos problemas que impiden que Jack maneje correctamente el código de bytes generado por Kotlin ( 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 clases modificados utilizando Jill durante la compilación incremental, en lugar de traducir todos los archivos de clases cada vez (que es el único comportamiento posible en las antiguas herramientas de Android).

Entonces, como dijo @LukasBergstrom, no habrá ningún problema con "atascar en el pasado" ;-)

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

Codificación feliz.


0

Según el blog de Kotlin , versión 1.1-beta2 de la sección Nuevas funciones:

Soporte para construir proyectos de Android cuando la cadena de herramientas Jack está habilitada (jackOptions {true});

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.