El hecho de que Google haya decidido migrar parte de la implementación de Java que ellos mismos crearon “basándose en la de Oracle”, y tantos problemas les ha dado (sobre todo a nivel legal), es un claro acontecimiento. La noticia ha saltado a raiz de la pista encontrada en un commit en el código fuente de la futura nueva versión de Android N. Cambios que veremos en los próximos meses.
La comunidad Android se ha lanzado a valorar este hecho, tanto desarrolladores como usuarios apasionados del sistema operativo de Google. Quizás es un tema más del tipo developer, pero vamos a tratarlo desde los distintos ángulos posibles. El titular con lo que muchos se han quedado ha sido, evidentemente, que esto aliviará las disputas entre Oracle y Google, pero hay mucho más.
¿De qué parte de Android estamos hablando?
Incorporar OpenJDK en Android implica cambios interesantes, nada triviales, en la parte Core de Android. Es decir, las Core Library y su entorno de ejecución
Cuando hablamos de Android y Java parece que siempre ha rehuido de dicho lenguaje. Android surgió como una evolución, salvando las distancias, de lo que hasta ahora se estaba haciendo con Java en dispositivos móviles: las aplicaciones J2ME. ¿Te acuerda de alguna de ellas en sus Nokia de la época? Android surgió como algo totalmente nuevo. El objetivo era crear un sistema operativo potente utilizando y adaptando runtime específico para dispositivos móviles utilizando lo que se pudiera (y dejarán) de J2SE.
Obviamente para ello había que usar la parte Open Source de la plataforma, así que Apache Harmony era la herramienta idónea para crear el framework de Android, sus Core library y su maquina virtual. En aquel momento era el proyecto que mejor luchaba por una implementación libre del estándar de Java apoyándose por la comunidad. OpenJDK aún no existía.
De Apache Harmony surgió Dalvik, la maquina virtual que ejecuta Android, y posteriormente ART a partir de Android 4.4. De este modo, ** Dalvik no es 100% Java SE** ni incorpora las librerías de Java 2ME, AWT o Swing, por poner un ejemplo.
De este modo, incorporar OpenJDK en Android implica cambios interesantes, nada triviales, en la parte Core de Android. Es decir, las Core Library y la maquina virtual. Esto a día de hoy, por ejemplo, limita la versión de Java soportada: actualmente Java 7.
¿Cuáles son los motivos?
El motivo principal es meramente técnico: Android había quedado obsoleto respecto al actual Java
Quizás lo primero que se nos ha venido a la cabeza tras conocer las noticias haya sido la disputa legal entre Oracle y Google. ¿Podría ser que finalmente Google tome la iniciativa de eliminar vestigio del dichoso código propietario de Oracle? Quizás, eso aliviará las disputas pero a día de hoy no es una razón de peso.
Oracle ha luchado en los tribunales desde 2010 contra Google y su sistema operativo. Un culebrón que lleva años ocupando parte de las tertulias sobre Java y Oracle. Con distintas sentencias a favor y en contra. Lo cierto, que como ya comentaban desde VentureBeat dar un paso atrás no haría ningún favor a Java, dando por hecho que las APIs tiene propiedad intelectual clara de Oracle. Y siendo, sinceros a día de hoy Java es de Oracle.
Fuera de todas esas disputas legales más propias de abogados, me decanto más por la evolución natural de la tecnología.
El Java que dispone Android no es del todo compatible con las últimas versiones. El hecho de que sólo esté soportado Java 7 impide que los desarrolladores puedan utilizar algunas funcionalidad interesantes en sus desarrollos, al igual que las mejoras de rendimiento del entorno de ejecución en Android, ART que se vería beneficiada.
Apoyándonos en la premisa de la mejora técnica de la plataforma, sin duda, el futuro de OpenJDK se presenta bastante atractivo en dispositivos móviles. Ya se anunció en la pasada Java ONE cuando Oracle dió sus planes sobre Java y la plataforma. Suya fue una propuesta para portar el JDK a las plataformas móviles como Android, iOS o Windows Phone. Mejoras de rendimiento y, por supuesto, adaptación a la naturaleza propia de los dispositivos (batería, procesadores, etc..). Con esto se hará posible que Java 9 esté disponible casi con el lanzamiento de la nueva versión en arquitecturas de 64bits.
¿Qué implicaciones tiene para usuarios y los desarrolladores?
El futuro de OpenJDK está centrado en los dispositivos móviles. Los desarrolladores serán los principales beneficiados. Si no fallan los planes veremos Java 9 en Android
Este cambio dentro del código interno de Android tiene implicaciones principalmente para desarrolladores.
Como comentamos antes, Android necesita ponerse a la cabeza de Java. A día de hoy es uno de los mayores impulsores del uso del lenguaje. Ya se sabe que por necesidad y, aunque muchos busque alternativas en Dart, Scala o Kotlin, sigue siendo el lenguaje oficial soportado.
Migrar el codebase de Android a OpenJDK es un beneficio claro a Java y lo refuerza frente otras soluciones. Con este cambio podremos pasar de Java 7 hacia ya no sólo Java 8, sino a poder tener Java 9 de forma equivalente a otras plataformas. Eso sí, recordar que el cambio vendrá en Android N, por lo que aún tendremos que ver cómo podemos hacer la compatibilidad con otras versiones anteriores.
Para los usuarios podemos apuntar que ello implicará con prácticamente total seguridad un mejor rendimiento de su peculiar maquina virtual de Android. Los futuros desarrollos de ART (Android Runtime) contará con las mejoras de OpenJDK con las arquitecturas Android para una mejor compilación en bytecode, algo que se había quedado desfasada con el proyecto inicial de Harmony.
Esperaremos ansiosos a las primeras versiones de Android N para ver tanto la mejoras de los herramientas para desarrolladores como los anuncios del rendimiento interno de Android con nuevo vitaminado Android Core basado en OpenJDK.
En Xataka Android | Android N no tendrá problemas legales con Oracle, usará OpenJDK, la versión libre de Java
Ver 18 comentarios