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 que 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á viva 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.
¿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 abiertos de prioridad P1/P2/P3 para la última versión de 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, 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 ni Oracle JDK por lo que comparar las diferencias con ellos es una tarea titánica. En la “version 8.0 Service Refresh 5” se han corregido unos 300 defectos (1.000 aprox. 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. El GitHub de SapMachine es aún más desolador… O lo parecía hasta que me informaron de:
Please notice that the SapMachine issue tracker is mainly used internally by the SapMachine team to organize its work (i.e. sync with upstream, downporting fixes, add SapMachine specific features, etc.).
Léelo en GitHub aquí
General VM/JDK bugs are maintained directly in the OpenJDK Bug System. You can open a SapMachine issue with a reference to an open or resolved OpenJDK bug if you want us to resolve the issue or downport the fix to a specific SapMachine version. If you find a general VM/JDK bug in SapMachine and don’t have write access to the OpenJDK Bug System you can open an issue here and we’ll take care to open a corresponding OpenJDK bug for it.
Every SapMachine release contains at least all the fixes of the corresponding OpenJDK release it is based on. You can easily find the OpenJDK base version by looking at the SapMachine version string.
Aún creo que ese primer párrafo ofrece poca visibilidad y para los usuarios finales “cada versión de SapMachine contiene al menos todos las correcciones de la versión de OpenJDK correspondiente” puede ser vaga y compleja de contrastar. De cualquier manera el mero hecho de hacernos llegar los comentarios hace sentir que se preocupan por su producto.
Zulu systems no parece tener un sistema público de búsqueda de bugs, pero se puede encontrar información de sus versiones 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.
? Sigue leyendo: Java 11 vuelve para quedarse
Juan Tavira
Universia
Especialista, arquitecto y friki multidisciplinar apasionado de todas las innovaciones. Esto es fácil de decir por uno mismo, pero cuando lo dicen mis compañeros informáticos, mis amigos geeks de los juegos e incluso mi mujer, algo de verdad tendrá ;-). Me gusta construir violines como hobby. En ocasiones veo código.
