Migración de Java 8 a Java 11

3
3798
Migración Java 8 a 11

Hace tiempo que salió la versión 11 de Java (de hecho ya tenemos la 12 e incluso empezamos a ver la 13), al igual que vemos que el soporte de Oracle para Java 8 llega a su fin. Con esta situación y teniendo en cuenta lo altamente extendido que está Java 8 a muchos les surge la duda de migrar o no, cuándo es el mejor momento y a dónde?!?! ya que el panorama de JVMs ha cambiado totalmente desde los tiempos donde Oracle e IBM eran prácticamente las únicas opciones.

En este tutorial veremos cuándo y por qué migrar, y cuáles pueden ser las mejores opciones de JVM.

1. Java 8

1.1. Futuro de Java 8

La respuesta corta sería: No tiene futuro

En general, y pasa no sólo con Java y Oracle, todas las versiones de todos los productos nacen para morir. Es decir, tienen un ciclo de vida que acaba en algún momento donde se le deja de dar soporte. Normalmente, en este ciclo de vida, la mejor opción es saltar a la siguiente versión antes de que la actual se quede sin soporte oficial. Así siempre conseguiremos:

  • estar bajo una versión con soporte,
  • adaptarnos poco a poco a las características de las nuevas versiones.

En el caso concreto de Java 8 según Oracle (https://www.oracle.com/technetwork/java/java-se-support-roadmap.html) las actualizaciones gratuitas para uso personal estarán hasta final de diciembre de 2020, pero para uso comercial terminaron en enero de 2019 (así que a día de hoy ya no tiene soporte).

Para las opciones de pago por soporte los plazos de Oracle son:

Esto quiere decir que con las opciones de pago conseguimos extender un poco más el soporte pero no mucho más (realmente máximo 5-6 años).

Más información sobre versiones Java de Oracle:

new-JDK-release-model-Dalibor-Topic
Extraído de la presentación mencionada justo antes de Dalibor Topic

​1.2. ¿Merece la pena pagar soporte Java para seguir teniendo actualizaciones de Java 8?

No, no merece la pena puesto que es retrasar lo inevitable, no durante demasiado tiempo (como hemos visto en el punto anterior) y encima a un coste que según nuestra implantación puede ser para nada despreciable.

Costes máximos (https://www.oracle.com/technetwork/java/javaseproducts/overview/javasesubscriptionfaq-4891443.html):

Además, mientras más paguemos, más distancia habrá entre la versión obsoleta y la que esté en ese momento en vigor, y por tanto cuando finalmente nos quedemos sin soporte y no nos quede más remedio que actualizar de versión, aumentará la dificultad de migración y errores asociados (es más fácil cambiar poco pronto que mucho tarde).

Para mi pagar el soporte para mantener una versión ya obsoleta es “cavar nuestra propia fosa a golpe de talonario”.

El único caso que podría tener sentido es si estamos hablando de un sistema que vamos a dejar morir y que no vamos a evolucionar. En tal caso sí puede merecer la pena continuar con Java 8 y no hacer el esfuerzo de migrar, ya que estamos hablando de algo que se va a descontinuar.

1.3. ¿Qué caminos está tomando la empresa privada?

Todo el mundo está migrando a las nuevas versiones y de hecho en mi opinión parece que el nuevo ciclo de versiones cada 6 meses y la apertura con el OpenJDK ha sido una bocanada de aire fresco que ha revitalizado todo el ecosistema Java, que últimamente algunos querían dar por muerto y nada más lejos de la realidad.

Lo que sí veo es que no se está adoptando el ciclo de releases cada 6 meses para entornos de producción (sobre todo de grandes empresas) y se están eligiendo los ciclos de las LTS (Long Term Support), lo que tiene bastante sentido.

2. Migración de Java 8 a Java 11

2.1. Necesidades de cambiar a Java 11, pros y contras

Más que una necesidad es una obligación para no quedarnos anclados en una versión obsoleta y sin soporte.

Como ventaja a nuestro favor tenemos el excelente trabajo que ha hecho siempre Java manteniendo compatibilidad hacía atrás, por lo que las migraciones no suelen ser complicadas (más adelante hablaremos de qué puntos tener en cuenta a la hora de migrar de Java 8 a 11).

Otro punto que juega a nuestro favor si actualizamos la versión de Java son las mejoras de la JVM. Constantemente en cada versión de la JVM se hacen mejoras de rendimiento, gestión de memoria con el Garbage Collector, y en general de uso de recursos, incluso de tiempo de arranque. Todas estas mejoras las disfrutaremos sin necesidad de cambiar nuestra base de código.

2.2. Recomendación: Oracle JDK vs. Open JDK

Para mi la opción recomendable es el OpenJDK dentro de alguno de sus sabores. Y esto no es por el coste, sino por la capacidad de mantenimiento y otras cualidades que nos proporciona el código abierto.

De hecho, siempre tenemos la opción de pagar por un soporte específico ya que hay distintas empresas que se dedican a ello, como por ejemplo:

Lo que está claro es que debido a las restricciones que ha puesto Oracle para el uso de su JDK con propósitos comerciales, podríamos decir que ahora se ha abierto la veda y han surgido numerosas alternativas.

Si por ejemplo nos fijamos en SDKMAN (https://sdkman.io/), conocida herramienta para instalar de forma simultánea distintos Software Development Kits

nos encontramos con las siguientes opciones de instalación para Java 11:

Tenemos que tener en cuenta que todas estas alternativas no son más que distintas builds del mismo código fuente, el del OpenJDK (http://openjdk.java.net/projects/jdk/), así que salvo esa pequeña personalización que haga cada proveedor, el código origen es el mismo.

De hecho todas pasan un proceso de certificación por la Java Community Process (https://www.jcp.org), que es la que otorga el Technology Compatibility Kit (TCK, en algunos casos también referido como JCK).

openJDK-many-builds
Imagen sacada del artículo original https://blog.joda.org/2018/09/time-to-look-beyond-oracles-jdk.html de Stephen Colebourne.

Diferencias entre Oracle JDK y OpenJDK (https://www.baeldung.com/oracle-jdk-vs-openjdk)

  • Lo más importante del artículo es que NO hay una diferencia técnica real entre los dos, ya que el proceso de compilación para Oracle JDK se basa en el de OpenJDK. Quizás, la única diferencia real puede ser la estabilidad que Oracle garantiza en la versión con soporte oficial, mientras que en el caso de OpenJDK las actualizaciones más frecuente pueden generar ciertos casos puntuales de inestabilidad.

De todas las opciones posibles, la «mejor» seguramente va a depender del uso que le queramos dar, así que sería bueno hacer algunas pruebas de carga y ver resultados. Por ejemplo:

  • si estamos dispuestos a cambiar de versión cada 6 meses podemos seguir ligados a Oracle (11.0.2-open),
  • pero si no queremos soportar este ritmo de versionado y sí contar con un ritmo constante de actualizaciones de mantenimiento/seguridad seguramente la opción más recomendable sea AdoptOpenJDK (11.0.2.hs-adpt en su sabor con HotSpot por ser más estándar).
  • Una muy buena opción puede ser Azul Systems (11.0.2-zulu) con buena cadencia de mantenimientos y opciones de soporte comercial.
  • Si ejecutamos en entornos concretos puede que las OpenJDKs propias del fabricante sean buenas opciones. Por ejemplo, si ejecutamos en AWS usar la de Amazon (11.0.2-amzn).

Si sólo pudiera elegir una, a día de hoy seguramente me quedaría con AdoptOpenJDK (11.0.2.hs-adpt), por lo menos para empezar y luego ver si damos el salto a otra más específica por razones concretas. Además tiene el respaldo de grandes compañías como IBM, Microsoft Azure, Azul Systems, jClarity…

Documento muy recomendable sobre las distintas alternativas de JDK, elaborado por los Java Champions comunidad de líderes y expertos independientes de Java:

2.3. Implicaciones del cambio a Open JDK

En principio ninguna ya que:

  • la comunidad de OpenJDK crea y mantiene la Implementación de Referencia (RI) open-source (GPLv2+CE)
  • de la especificación de Java SE,
  • gobernada por la Java Community Process (JCP),
  • y definida bajo el paraguas de la Java Specification Request (JSR) para cada una de sus features.

Es decir estamos tratando con una especificación que todas las implementaciones deben cumplir por igual.

Y digo ‘en principio’ porque no dejamos de hablar de software y por lo tanto, cada implementación puede tener sus propias pequeñas diferencias o bugs.

Pero esas diferencias deberían ser menores de lo que ya existía hasta ahora con las diferentes implementaciones que teníamos como la de Oracle o la de IBM, ya que ahora todas parten del mismo fuente: OpenJDK.

Esas diferencias deberían ser sólo en funcionalidades no-core, como monitorización extendida, diagnóstico, herramientas, etc.

2.4. Modelo de migración: ¿Se puede pasar directamente de Java 8 a 11 o es necesario hacer una migración escalonada?

Sí, se puede migrar directamente, y de hecho sería lo recomendable ya que Java 11 es una Long-Term-Support (LTS) release (https://www.oracle.com/technetwork/java/java-se-support-roadmap.html). Las LTS son versiones cuyo compromiso de mantenimiento es de 3 años. Entre medias saldrán varias versiones non‑LTS (como la 9 la 10, 12, …) donde cada una de estas versiones añade funcionalidad pero que, a ritmo de 6 meses, será reemplazada por otra versión. Si no queremos enfrentarnos a este ritmo de actualizaciones lo mejor es mantenernos en las LTS.

Para realizar la migración podemos encontrar por Internet mucha literatura, por ejemplo si buscamos en Google «java 11 java 8 compatibility» obtenemos referencias como:

Un resumen de los puntos a tener en cuenta para la migración podría ser:

2.5. Evolución de los principales framework, componentes de desarrollo y servidores web

La tendencia de las herramientas, frameworks, librerías y en general de todo el ecosistema es ir actualizándose y soportar el ciclo de releases de 6 meses.

Así encontramos múltiples ejemplos de como las más típicas ya han hecho su migración a Java 11 hace tiempo:

2.6. Alternativas a JNLP

Java Network Launch Protocol (JNLP) (https://docs.oracle.com/javase/tutorial/deployment/deploymentInDepth/jnlp.html) es el protocolo que permite a un aplicación ejecutarse en un escritorio cliente usando recursos que se encuentran en un servidor web remoto.

Java Plug-in y Java Web Start se consideran clientes de JNLP.

Todas esta tecnologías (JNLP, Web Starts, Applet, …) desaparecen en Java 11, por lo que NO hay una alternativa directa (https://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf). Así que si estamos usando alguna de estas tecnologías es posiblemente el peor punto de la migración a Java 11 y habrá que ver cada uno de los casos.

Para aplicaciones de escritorio “stand-alone” que distribuimos mediante Java Web Start podemos usar alguna de estas alternativas:

Para aplicaciones Web donde el Applet es simplemente el frontal, habría que reescribir este front en otra tecnología HTML + JavaScript, usando algún framework como Angular, React, o similares (siendo esta la tendencia de mercado para aplicaciones web ricas).

3. Conclusiones

Si pretendes que tu sistema dure todavía unos cuantos añitos, migra lo antes que puedas.

Si lo vas a descontinuar mantente en Java 8.

Y en cualquier caso salte de la JDK de Oracle y vete a otra (por ejemplo la de AdoptOpenJDK), y si más adelante ves que necesitas soporte específico, contrátalo a alguna de las empresas que lo dan de forma profesional.

4. Sobre el autor

Alejandro Pérez García (@alejandropgarci)

Ingeniero en Informática (especialidad de Ingeniería del Software) y Certified ScrumMaster

Socio fundador de Autentia Real Business Solutions S.L. – «Soporte a Desarrollo»

Socio fundador de ThE Audience Megaphone System, S.L. – TEAMS – «Todo el potencial de tus grupos de influencia a tu alcance»

3 Comentarios

  1. Hola Alejandro, tu articulo me aclaro algunas dudas, sin embargo aún tengo el siguiente planteamiento:

    Yo puedo programar con Oracle JDK 11, 12.. y las que vengan, principalmente hago aplicaciones web (WAR), que no necesitan más que tomcat (el cual solo necesita JRE) para funcionar. Mis preguntas son las siguientes:

    1.- ¿puedo seguir programando con el JDK de Oracle, generar el WAR y montarlo en producción en un tomcat que solo requiere el JRE (11,12, etc.)?, por lo que he leído si es factible, en donde veo que no podría aplicar, es cuando usas un servidor de aplicaciones en producción que SI requiere el JDK.

    2.- Suponiendo que yo tengo una empresa y quiero usar un -servidor de aplicaciones- que necesita de JDK, para uso en mi LAN, es decir interno, supongo que tampoco tendría problema.

    ¡Saludos!

    • Pues te diría que en ambos casos estas afectados igualmente.

      En el 1. porque ya no existe la distinción entre JRE y JDK, básicamente porque al JRE ya no se distribuye, sino que sólo puedes instalar la JDK (https://dzone.com/articles/no-more-jre-packaging-no-big-deal-1) que es todo el tema de licencias que he comentado en el artículo.

      En la 2, si usas la «Oracle JDK» (ojo que no estamos hablando de la «open») tendrás los mismos problemas de licenciamiento y tendrás que pagar por ella, da igual que sea en una red local o visible desde internet.

      Tu mejor opción es pasarte a alguna de las alternativas abiertas como el AdoptOpenJDK y así que te quitas de problemas.

      Saludo y muchas gracias!

      • Gracias Alejandro, por tu pronta respuesta, ahora tengo un panorama más claro y hacia donde debo de apuntar. Tu articulo es de mucha ayuda en esta transición de Oracle JDK hacia Open JDK (para los que requieran). ¡Saludos!

Dejar respuesta

Please enter your comment!
Please enter your name here