android - java 8 tutorial
Cómo Jack(Java Compiler Kit de Java) afectará a los desarrolladores de Scala (3)
Ahora, con el anuncio de Jack Google, se aclaró el futuro previsible de Java en relación con Android. Pero, ¿cuáles son las implicaciones para Scala y otros desarrolladores de lenguajes basados en JVM? En particular:
- Scala lo hace por su propio compilador que produce bytecode de Java. Pero Jack toolchain no se ocupa de bytecode . ¿El bytecode generado obtendrá algún beneficio de optimización del procesamiento de Jack?
- A partir de Scala 12 solo se admite Java 8+. Ese es el bytecode generado también es Java 8+. ¿Puede Jack utilizar Java bytecode (sin o con limitaciones)?
- ¿Se pueden usar las características de Java 8 recientemente soportadas para desarrollar versiones anteriores de Android (minSdkVersion <''N'') o debería mantener una rama separada para cada versión de Java? (no está claro en la documentación).
Todas estas preguntas se reducen a una: ¿se puede usar Scala para el desarrollo de Android en el futuro sin sacrificar los beneficios de las nuevas funciones de Scala y la nueva cadena de herramientas de Android?
Lectura relacionada:
por favor comparte enlaces relacionados en comentarios o respuestas
Preguntas relacionadas:
Relacionado:
Por favor vote por la solicitud de función de la herramienta Jack:
EDITAR:
Estoy intentando razonar (NO responder) mi pregunta esperando que los expertos me corrijan si estoy equivocado.
A continuación se muestra un flujo hipotético de compilación de Jack con algunos bloques adicionales que se agregaron según mi lógica y lo que aprendí de los documentos disponibles.
La suposición base es que Dalvik admite hasta instrucciones de bytecode de Java 7. Si eso es correcto, las instrucciones de Java 8 no se pueden pasar directamente a Dalvik, sino que de alguna manera deben transformarse en Java 7. (Puede ser algo similar a lo que siempre hace el compilador de Scala).
Entonces, la pregunta es dónde ocurre esa transformación. Parece que Jill no puede procesar el bytecode de Java 8 por ahora, por lo que posiblemente ocurra en el bloque (3) de flujo hipotético. Si eso es correcto, solo los archivos del proyecto fuente de Java están sujetos a transformación y la respuesta a la pregunta 2 es: No. Las clases Java 8 de las bibliotecas no pueden utilizarse hasta que Jill pueda hacerlo (si es posible) . Es decir, no podemos usar Scala 12+.
Si la optimización de todos los códigos se realiza en el bloque (6), la respuesta a la pregunta 1 es: sí. El código de Scala que se convierte a la biblioteca .jar puede beneficiarse de las optimizaciones de Jack. Pero preliminarmente debe transformarse en .jayce (representación AST-like) que aumentará el tiempo de compilación.
Y, finalmente, Jack produce el bytecode .dex Dalvik para mantener la compatibilidad con los tiempos de ejecución antiguos de Dalvik (ART también consume bytecode de Dalvik). Entonces, la respuesta a la pregunta 3-d es: Sí, se pueden usar las características de Java 8. Pero solo en proyectos de fuentes Java. La aplicación todavía es compatible con cualquier tiempo de ejecución. Pero las ventajas de Java 8 se eliminan debido a la conversión a Java 7 (código de byte Dalvik).
Es importante entender que hay 2 herramientas introducidas:
Jack : un nuevo compilador para reemplazar el complicado javac + proguard + dx
Jill : un enlazador de biblioteca que podrá vincular las bibliotecas compiladas actualmente (.class) y más.
Ver http://tools.android.com/tech-docs/jackandjill
Entonces parece que hay 2 problemas separados aquí:
Compatibilidad Scala :
Scala no será compatible con Jack, ya que Jack compila el código fuente de Java.
Sin embargo, Scala 2.11 compila el bytecode de Java 1.6 y, por lo tanto, Jill podrá elegir ese código y convertirlo a archivos jack para alimentar el compilador de Jack.
Ver Android N Java 8 características (compilador de Jack) y Kotlin interoperabilidad (Kotlin es el mismo problema que Scala, ya que es un lenguaje JVM)Java 8, y por lo tanto Scala 2.12+, compatibilidad :
Esta parte está en desarrollo, si Jack / Jill admite Java 8, entonces también será compatible con Scala 2.12+ (a través de Jill). Si no, los desarrolladores de Java 8 están en el mismo barco que los desarrolladores de Scala 2.12.
En el caso de que Jack soporte Java 8 pero no Jill, entonces los desarrolladores de las bibliotecas de Java 8 estarán en el mismo bote que los desarrolladores de Scala 2.12.
Ver https://www.guardsquare.com/blog/DroidconLondon2015
Google acaba de anunciar que la cadena de herramientas Jack desaprobará la cadena de herramientas Jack y Android agrega "compatibilidad con las características del lenguaje Java 8 directamente en el conjunto de herramientas javac y dx actual"
Fuente: https://android-developers.googleblog.com/2017/03/future-of-java-8-language-feature.html
Sabemos cuánto le importa a nuestra comunidad de desarrolladores de Android la buena compatibilidad con las características del lenguaje Java 8, y estamos cambiando la forma en que las apoyamos.
y:
Hemos decidido agregar soporte para las características del lenguaje Java 8 directamente en el conjunto de herramientas javac y dx actual, y desaprobamos la cadena de herramientas Jack.
Joan tiene razón, pero creo que Jill tendrá soporte para Java 8 en algún momento, de lo contrario será imposible usar Java 8 en las bibliotecas de Android que serán consumidas por las aplicaciones de Android, ya que empaquetan su código en un archivo jar dentro de aar y no veo que este cambio de formato ocurra pronto en ningún lado. De todos modos, solo podemos adivinar, ya que Google es actualmente una blackbox con respecto a ese tipo de cambios.
Revisando desde que se publicó la nueva información en 2017: Jack Toolchain ahora está en desuso y la pila antigua dex / javac recibirá soporte java8, por lo que nada cambiará ahora para Scala.