Desarrollo

¿El fin de Java se encuentra tras la versión 11?

03/11/18
No es un hecho, pero tampoco una ilusión. El fin de Java es una de las múltiples alternativas de los posibles futuros de Java (esperemos que no la más probable) y estar informado nos puede ayudar a evitar el desastre (pon aquí tu frase favorita de película de ciencia ficción) 😉
 
Ha habido dos grandes hitos con los últimos anuncios de Java: uno es el plan de liberar una versión de Java cada 6 meses; el segundo es la restricción de uso que Oracle impone en su licencia de uso Oracle JDK, pero no en la compilación de OpenJDK que se libera con licencia GPL.

¿Qué consecuencias tendrá esto?

La primera nos indica que Java 10 dejó de tener actualizaciones desde septiembre de 2018, aunque Java 8 tendrá algunas hasta al menos diciembre de 2020. Esto es un gran cambio en comparación con los ciclos de 3 años que eran lo habitual en versiones anteriores. Java 8 parece ser la versión más recomendable para tener como objetivo. Hay bastante tiempo para decidir antes de que ocurra algo serio.
 
Supongamos que en el 2021 aún estamos usando Java 8 ¿qué ocurriría? Java 8 pasaría a ser una versión obsoleta, sin parches, ni tan siquiera los de seguridad. Y eso es malo para cualquier aplicación conectada. En ese caso las opciones serían actualizar las aplicaciones a Java 11 (ya que es una versión LTS, es decir, con soporte prolongado) o a Java 15 que presumiblemente será la versión de Java más reciente en ese momento.
 
Y aquí aparece el segundo anuncio.
Tanto si usas Java 11 como Java 15 en su versión Oracle, ambos están regidos por el segundo anuncio:

“License Rights and Restrictions

Further, You may not:
– use the Programs for any data processing or any commercial, production, or internal business purposes other than developing, testing, prototyping, and demonstrating your Application;”

Esto nos lleva al hecho de que se necesita un acuerdo de licencia con Oracle para desplegar tu aplicación en Producción, con el beneficio de tener soporte, claro. Parece que Oracle ha tardado 8 años (desde que compró Sun, que era el dueño de Java) en dar el paso para rentabilizar Java SE; Java ME y otros componentes ya requerían licencia (este fue uno de los problemas con Android y los largos juicios con Google).

Pero, ¿ Java no era gratis?

Más o menos. Java es libre, pero los binarios y las compilaciones de Java no lo son, por lo que el problema está en usar los binarios de una compañía que requiera su licenciamiento, como Oracle, y que habrá que pagar por ellos.

Entonces, ¿Qué opciones hay además de Oracle?

IBM developer kit incluye Java versión 8 y la última versión liberada es “Java 8 service refresh 5 fix pack 22”, liberada el 27 de septiembre de 2018. Esto nos indica que está vida y, además, tiene diversas plataformas para elegir. La licencia de IBM no parece restringir su uso en Producción (nota: esto es una apreciación de su lectura, no una afirmación legal)
 
También tenemos la opción de OpenJDK que, a la publicación de este artículo, sólo tenía binarios para x64 en Linux, macOS y Windows.
 
SapMachine entra en la misma categoría que OpenJDK ya que ellos se autodefinen como un fork amigable (aunque incluyen la arquitectura ppc64 como extra) e igualmente Eclipse J9 que añade Linux s390x como plataforma disponible.
 
Y finalmente llegamos a Zulu, una compañía que sigue los pasos de otros que tienen oferta de productos open source: tienen una versión de OpenJDK con versiones community y empresarial, así como soporte.
 
La pregunta que debemos hacernos ahora es: ¿Qué podemos esperar de cada una de estas opciones? ¿cómo quedan en comparación con la JDK de Oracle? ¿Serán seguras y evolucionarán a ritmos adecuado?
 
OpenJDK tiene sistema público de seguimiento de bugs. A fecha de hoy sólo tiene 9 bugs de prioridad P1/P2/P3 para Java 8. Afortunadamente Oracle sigue la misma nomenclatura en su sistema, en el que se pueden hacer búsquedas. Ocho de esos nueve se pueden encontrar en la web de Oracle, con la única excepción de JDK-8200110 que está relacionada con un error de cadena en la compilación del GCC, un defecto menor prácticamente irrelevante. OpenJDK parece una buena opción, hasta que las pruebas de tu aplicación demuestren lo contrario, si es que eso ocurre.
 
“IBM SDK, version 8 fixes” se puede encontrar en su web, no siguen la misma nomenclatura que OpenJDK u Oracle JDK por lo que comparar las diferencias con ellos es una tarea titánica. Pero en la “version 8.0 Service Refresh 5” se han corregido unos 300 defectos (y alrededor de mil entre todos los parches de la versión 8) por lo que parece que en términos de defectos la versión Java de IBM parece bastante fiable. También relacionan sus versiones con las de Oracle 8. Una buena alternativa.
 
Por otro lado, OpenJ9 para Java 8 sólo tiene 9 incidencias abiertas de un total de 40, parecen números muy pequeños para un producto fiable. Y el GitHub de SapMachine es aún más desolador.
 
Zulu systems no parece tener un sistema público de búsqueda de bugs, pero se puede encontrar información de sus versiones [17] y como se mapean con las de OpenJDK, por ejemplo, Zulu Release 8.33 y 8.32 del 18 de octubre de 2018 se mapean con Java SE update 191 y 192. No parece una mala opción, pero de manera similar a Oracle se centran en tener una versión comercial de la que poder cobrar el soporte.
 
Este es el panorama actual de Java. La raíz de todos nuestros desarrollos y frameworks se ha resquebrajado, pero aún hay tierra firme a la que recurrir, hasta algo que no sea Java surja y tambalee el mundo de los desarrolladores. “Ojalá vivas tiempos interesantes” dice la antigua maldición china.

Autor: Juan Tavira

 

Santander Global Tech

 

Otros posts