El abismo de tux

En este megapost mi objetivo es consolidar todas las dificultades (y soluciones) que he enfrentado al actualizar proyectos Java EE y/o MicroProfile desde Java 8 hacia Java 11. Es un hecho que Java 11 trajo consigo muchas características que cambiaron el ecosistema de Java y podrían ser problemáticas durante nuestras actualizaciones.

Aunque mi enfoque es Java empresarial, esta información puede servir de referencia para actualizaciones con otros frameworks/runtimes.

Este ha sido el post más largo que escribo en varios años por lo que agradecería que lo compartieran 😬.

¿Es posible actualizar proyectos Java EE/MicroProfile desde Java 8 hacia Java 11?

Si. En anteriores ocasiones he actualizado junto a mi equipo dos proyectos que considero épicos (más de 3 años de desarrollo) con las siguientes métricas:

Proyecto 1: Un sistema de gestión empresarial (MIS)

• Tiempo invertido en la migración: 1 semana
• Módulos: 9 EJB, 1 WAR, 1 EAR
• Clases: 671
• Líneas de código: 39480
• Inicio del proyecto: 2014
• Plataforma original: Java 7, Wildfly 8, Java EE 7
• Plataforma actual: Java 11, Wildfly 17, Jakarta EE 8, MicroProfile 3.0
• Cliente web: AngularJS

Proyecto 2: Un sistema de venta y geocerca

• Tiempo invertido en la migración: 3 semanas (por varios errores en upstream)
• Módulos: 5 WAR/Microservicios
• Clases: 348
• Líneas de código: 17160
• Inicio del proyecto: 2017
• Plataforma original: Java 8, Glassfish 4, Java EE 7
• Plataforma actual: Java 11, Payara 5, Jakarta EE 8, MicroProfile 3.2
• Cliente web: Angular

¿Porqué debería actualizar hacia Java 11?

Como todo en informática la respuesta es: depende. Los motivos por los cuales he decidido actualizar suelen ser los siguientes:

1. Reducir la superficie de ataque al contar con dependencias actualizadas, especialmente Open Source
2. Reducir el débito técnico y preparar mis proyectos para un Java más dinámico
3. Aprovechar las mejoras de desempeño en las nuevas versiones de Java
4. Aprovechar las nuevas características de Java como lenguaje
5. Dormir bíen gracias a esas ventajas técnicas

¿Porqué es dificil actualizar un proyecto Java EE desde Java 8 hacia Java 11?

De acuerdo a mi experiencia y en orden de prioridades, por los siguientes motivos:

Cambios en la frecuencia de lanzamiento de Java

Actualmente tenemos dos grandes ramas de máquinas virtuales de Java

• Java LTS: El cual está pensado para soporte de largo plazo (3 años), siendo la última versión Java 11
• Java current: El cual está pensado para tener ciclos de vida cortos (6 meses) y recibir características de forma rápida, el cual al momento de escribir este articulo es Java 15

El raciocinio detrás de este cambio es que Java como plataforma necesitaba dinamismo y es más fácil recibir pequeñas características cada seis meses, con lo cual estoy totalmente de acuerdo.

Sin embargo es un hecho que la mayoría de frameworks empresariales están enfocando sus runtimes hacia Java 11 para estar en linea con ciclos de soporte de la JVM más largos.

El uso de módulos internos en la JVM

Errata: Actualicé y simplifiqué esta discusión siguiendo comentarios en Reddit

Java 9 introdujo cambios en clases internas que no estaban diseñadas para su uso fuera de JVM, evitando / rompiendo la funcionalidad de bibliotecas populares que hicieron uso de estos componentes internos para ganar velocidad y rendimiento, por ejemplo Hibernate, ASM o Hazelcast.

Por lo tanto y para evitarlo en el futuro, las API internas en JDK 9 se diseñaron de tal forma que de aca en adelante se busca que sean inaccesibles. De momento por defecto son inaccesibles en tiempo de compilación (pero accesibles con –add-export) y accesibles en tiempo de ejecución siempre y cuando la biblioteca ya exista en JDK 8. Con la salvedad de que en un futuro pueden ser inaccesibles por completo.

A largo plazo este cambio reducirá los costos soportados por los mantenedores del propio JDK y por los mantenedores de bibliotecas y aplicaciones que intencionalmente o no, hicieron uso de estas API internas.

Finalmente, durante la introducción de JEP-260, las API internas se clasificaron como críticas y no críticas, por lo que las API internas críticas para las que se introducen reemplazos en JDK 9 están obsoletas en JDK 9 y se encapsularán o eliminarán en una versión futura.

Esto para fines prácticos representa peligro en nuestros proyectos si:

• El proyecto se compila contra dependencias pre Java 9 que a su vez dependen de componentes internos críticos
• El proyecto incluye dependencias pre Java 9 que usan componentes internos críticos
• La aplicación se ejecuta en un servidor de aplicaciones que incluye dependencias que dependen de componentes internos críticos

En cualquiera de estas tres situaciones existe la probabilidad de que el proyecto no funcione sin actualizar dependencias, lo cual puede a su vez revelar incompatibilidades porque el API de alguna dependencia/biblioteca ha cambiado entre versiones -e.g. Flyway-.

Eliminación de CORBA y los módulos de Java EE en el JDK

Otro cambio importante en Java 9 fue que varios modulos de Java EE y CORBA fueron marcados como «Deprecated» para ser eliminados en futuras versiones de OpenJDK.

A partir de Java 11 este cambio se hizo realidad y varios módulos de OpenJDK que eran incluidos para soportar Java EE fueron eliminados de OpenJDK, con esto, los siguientes paquetes ya no son parte de OpenJDK:

• java.xml.ws (JAX-WS) para creación de servicios SOAP
• java.xml.bind (JAXB) para procesamiento de XML
• java.activation (JAF)
• java.xml.ws.annotation (Common Annotations)
• java.corba (CORBA)
• java.transaction (JTA)
• java.se.ee (Módulo agregador)
• jdk.xml.ws (Herramientas para JAX-WS)
• jdk.xml.bind (Herramientas para JAXB)

Para fines prácticos esto significó que ya no es posible generar y ejecutar clientes SOAP (o CORBA) directamente desde la JDK, y ahora es necesario agregar los proyectos upstream como en cualquier otra biblioteca.

El raciocinio detrás de este cambio fue que los módulos eran incluidos como una conveniencia para soportar la «nueva era» de Web Services en los 90s, pero que al final del día eran mantenidos por proyectos Upstream de forma independiente y los publicaban en Maven Central.

Independencia de JavaFX en OpenJDK

De la misma forma que los módulos de Java EE, en Java 11 el módulo de JavaFX fue removido y desacoplado de la distribución de Java Developer Kit, luego de 10 años de desarrollo.

Al igual que Java EE, el modulo sobrevive fuera de la distribución estándar del Java Developer Kit, y de hecho existe actualmente un proyecto independiente mantenido por la comunidad, además de empresas como Gluon, Azul Systems y Oracle -i.e. OpenJFX– para que JavaFX evolucione a su propio ritmo.

Entornos de desarrollo integrado y servidores de aplicaciones

Al igual que lo que pasó con las bibliotecas, los IDEs tuvieron que prepararse para la transición hacia Java modular, al menos en tres niveles:

• El IDE como programa Java debe ser compatible con JPMS
• El IDE debe soportar Java 9, 10, 11 … como lenguaje de programación
• El IDE es la base de un ecosistema de plugins que TAMBIÉN debe actualizarse para soportar JPMS
• Estos plugins a su vez deben ser compatibles con entornos de ejecución (servidores) compatibles con JPMS

Con esto tanto Netbeans como IntelliJ y Eclipse se actualizaron paulatinamente hacia Java 9 y superiores, PERO no podían dar garantías que todo el ecosistema estuviera actualizado.

Acá una situación común es que luego de instalar Java 11 y un IDE como Eclipse con soporte para Java 11, nuestro proyecto aun fuera incompatible porqué:

• Utilizábamos la versión un plugin -e.g. Glassfish- que aun NO era compatible con JPMS
• Utilizabamos un application server -e.g. Glassfish- que en la época aun NO era compatible con JPMS

Ok, ¿Como actualizo proyectos?

Dadas las situaciones anteriores, actualizar un proyecto desde Java 8 (o 7) es una tarea que requiere distintas verificaciones, por lo cual suelo una estrategia de 8 pasos:

1. Verificar la compatibilidad del entorno de ejecución
2. Verificar que versión de Java necesito
3. Configurar nuestro entorno de desarrollo para soportar múltiples JVM
4. Verificar el IDE
5. Actualizar y configurar Maven
6. Actualizar las dependencias del proyecto
7. Incluir manualmente las dependencias de Java/Jakarta EE
8. Ejecutar múltiples JVM en producción

1. Verificar el entorno de ejecución

Mike Loukides de O’Reilly considera que existen dos tipos de programadores y eso se hace evidente en Java. Por un lado están los programadores que crean los frameworks, bibliotecas y rutinas de bajo nivel y por otro lado están los programadores que utilizan estas herramientas para crear experiencias, productos y servicios.

Java Empresarial se encuentra en el segundo grupo, donde descansamos sobre hombros de gigantes y por este mismo motivo antes de intentar planificar cualquier actualización debemos de verificar que nuestro runtime/herramienta/servidor sea compatible (al menos) con Java 11. Afortunadamente el ecosistema de Java 11 ya es bastante maduro y varios proyectos fundamentales de Java han realizado la transición exitosamente, incluyendo:

• Apache Tomcat
• Apache Maven
• Spring
• Oracle WebLogic
• Payara
• Apache TomEE
• … entre otros

De hecho en bastante improbable que una biblioteca aun no soporte Java 11, pero si ese fuera el caso debemos indagar con el fabricante/comunidad si el proyecto no ha muerto, sus planes para el futuro o pensar en contribuir con el desarrollo para que esto suceda.

2. Verificar que versión de Java necesito

Una segunda limitante no técnica que podríamos enfrentar es que para una determinada versión de un producto necesitamos un Java Developer Kit en particular, lo que se conoce como el proceso de certificación.

En jerga informática solemos decir que un paquete de software esta certificado cuando el fabricante brinda garantías de que el mismo funcionara de forma correcta bajo ciertas condiciones/entorno. Dicho de otra forma puede que el software ya funcione bien bajo Java 11 pero es necesario tener la garantía legal y de soporte para proceder con una actualización.

Un caso ejemplo es WebLogic, que necesita por contrato una compilación especifica de OpenJDK para ejecutarse (Oracle Hotspot) y una versión mínima para aplicar a contratos de soporte.

Otro podría ser SAP el cual requiere que se utilice la compilación de OpenJDK soportada por SAP (SAP JVM) para ejecutar sus productos.

3. Soportar múltiples JVMs en desarrollo

Al ser la actualización un proceso experimental de tipo prueba y error, una buena idea es soportar multiples JVMs en desarrollo, y para esto existen diversas herramientas:

SDKMan

Disponible para entornos UNIX (Linux, Mac, Cygwin, BSD) permite la instalación de varias herramientas útiles en el ecosistema Java como Maven, Gradle, Leiningen, Micronaut y diversas compilaciones de OpenJDK -e.g. AdoptOpenJDK, Amazon Correto, Oracle GraalVM-.

jEnv

También disponible para entornos UNIX (Linux, Mac, Cygwin, BSD) es un script de configuración de entorno. Tiene la particularidad que permite configurar la JVM a nivel de sistema, red y usuario. Esta es mi elección personal ya que permite gestionar JVMs instaladas bajo diversos formatos.

En el caso de Windows la forma más fácil que he encontrado es automatizar la tarea con archivos .bat. Pero para serles franco no uso Windows para trabajo/desarrollo desde el año 2006. Agradecería cualquier comentario al respecto.

4. Verificar el IDE

Recordemos que un IDE se compone de 3 partes

1. La plataforma
2. El soporte al lenguaje de programación
3. Las extensiones para soportar herramientas especificas

Tanto Eclipse, NetBeans, IntelliJ IDEA y Visual Studio Code tienen versiones compatibles con Java 11 por lo que la tarea es actualizar hacia estas versiones.

Luego de la actualizacion y la ejecución sobre Java 11, debemos verificar si nuestras extensiones funcionan correctamente. Especialmente si se utilizan conectores hacia servidores de aplicaciones.

5. Actualizar y configurar Maven

Aunque existen otros sistemas como Ant, Gradle o Bazel, en mi opinión Maven sigue siendo el estándar de facto en la gestión de la configuración y dependencias de proyectos con Java.

Además de actualizar nuestra instalación de Maven, debemos tomar en cuenta que Maven como proyecto funciona a través de extensiones, las cuales se pueden forzar arbitrariamente. Por tal motivo debemos de estar seguros cual es la versión de plugins que utilizaremos en cada proyecto a compilar. En esta línea Maven cuenta con un POM (listado de dependencias) con versiones predeterminadas que deberíamos incluir en nuestros proyectos.

Una forma rápida de verificar las extensiones es utilizar versions-maven-plugin

<plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>versions-maven-plugin</artifactId>
      <version>2.8.1</version>
</plugin>

El cual tiene un «goal» especifico para mostrarnos las versiones disponibles de los plugins de Maven

mvn versions:display-plugin-updates

Como regla general debemos utilizar las últimas versiones estables para no tener problemas con Java 11.

Así mismo debemos de configurar Maven para que sea capaz de compilar código nivel 11, lo cual se hace generalmente en dos puntos del archivo de configuración.

En la propiedad maven.compiler.x:

<properties>
        ...
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
</properties>

En maven-compiler-plugin si lo tenemos configurado de forma explitica:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.8.0</version>
    <configuration>
        <release>11</release>
    </configuration>
</plugin>

Como medida de compatibilidad el équipo de la JVM disponibiliza desde Java 9 la bandera illegal-access para permitir acceso reflectivo a modulos internos de la JVM, esto quiebra la teoría de separación por modulos de JPMS pero permiten aumentar la compatibilidad de algunos paquetes con histórico acceso a clases internas.

En ocasiones necesitaremos invocar las extensiones con esta bandera, por en surefire y failsafe los cuales son utilizados tradicionalmente en Java EE para invocar la ejecución servidores de aplicaciones que necesitan este argumento:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.22.0</version>
    <configuration>
        <argLine>
            --illegal-access=permit
        </argLine>
    </configuration>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <version>2.22.0</version>
    <configuration>
        <argLine>
            --illegal-access=permit
        </argLine>
    </configuration>
</plugin>

6. Actualizar las dependencias de mi proyecto

Como se ha mencionado en la parte teórica del proyecto, es necesario actualizar todas las dependencias del proyecto hacia su última versión estable y/o compatible con Java 11.

Tomando en cuenta que a veces el salto mayor de dependencia -e.g. Flyway 4 hacia Flyway 6- implica un cambio en el API del proyecto, acá se debe considerar que podría ser necesario un refactoring de nuestro código, para ser sinceros esta es la parte que podría requerir más tiempo y lo que detiene a la mayoría de actualizaciones.

Un buen paso inicial es verificar las ultimas versiones estables utilizando también versions-maven-plugin:

mvn versions:display-dependency-updates

La salida nos informara que dependencias tienen nuevas actualizaciones:

Al momento de actualizar también debemos estar seguros que las dependencias son compatibles con mi entorno de ejecución y podría afirmar que esta es una fortaleza poco conocida de Java EE, al ser Java EE una dependencia única los servidores de aplicaciones/microframeworks se encargan de resolver conflictos de dependencias y suele ser una experiencia bastante fácil frente a abordajes «hazlo tu mismo».

7. Agregar los paquetes faltantes de Java EE (y tal vez migrar hacia Jakarta EE)

Aunque en proyectos modernos (REST) esto probablemente no sea un problema, en proyectos basados en Web Service SOAP o en bibliotecas muy especificas sera necesario que agreguemos las dependencias que fueron removidas de OpenJDK.

En el mundo Java EE por cada paquete suele haber dos dependencias:

• El API o interfaz de programación
• La implementación de referencia con el código del API

En este punto vale la pena evaluar tambien si no es buena idea realizar el cambio haciar Jakarta EE.

La historia corta es que en 2017 Oracle liberó la mayoria de propiedad intelectual sobre Java EE para que la especificación reciba mayores contribuciones de la comunidad, naciendo así el proyecto Jakarta EE bajo la fundación Eclipse.

Para fines prácticos Jakarta EE 8 tiene las mismas capacidades técnicas de Java EE 8 y los mismos paquetes. Actualmente la mayoria de servidores de aplicaciones modernos y Tomcat ya son compatibles con Java EE 8(WebLogic lo tiene considerado para el futuro).

Si deseamos hacer actualización y nuestro entorno de ejecución la soporta, debemos de reemplazar la dependencia de Java EE 8:

<dependency>
    <groupId>javax</groupId>
    <artifactId>javaee-api</artifactId>
    <version>8.0.1</version>
    <scope>provided</scope>
</dependency>

Por:

<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>8.0.0</version>
    <scope>provided</scope>
</dependency>

Asi mismo, puede que necesitemos las siguientes dependencias para compilar nuestro proyecto Java EE que originalmente eran parte de OpenJDK:

Java Beans Activation

Java EE

<dependency>
    <groupId>javax.activation</groupId>
    <artifactId>javax.activation-api</artifactId>
    <version>1.2.0</version>
</dependency>

Jakarta EE

<dependency>
    <groupId>jakarta.activation</groupId>
    <artifactId>jakarta.activation-api</artifactId>
    <version>1.2.2</version>
</dependency>

JAXB (Java XML Binding)

Java EE

<dependency>
    <groupId>javax.xml.bind</groupId>
    <artifactId>jaxb-api</artifactId>
    <version>2.3.1</version>
</dependency>

Jakarta EE

<dependency>
    <groupId>jakarta.xml.bind</groupId>
    <artifactId>jakarta.xml.bind-api</artifactId>
    <version>2.3.3</version>
</dependency>

Implementación

<dependency>
    <groupId>org.glassfish.jaxb</groupId>
    <artifactId>jaxb-runtime</artifactId>
    <version>2.3.3</version>
</dependency>

JAX-WS

Java EE

<dependency>
    <groupId>javax.xml.ws</groupId>
    <artifactId>jaxws-api</artifactId>
    <version>2.3.1</version>
</dependency>

Jakarta EE

<dependency>
    <groupId>jakarta.xml.ws</groupId>
    <artifactId>jakarta.xml.ws-api</artifactId>
    <version>2.3.3</version>
</dependency>

Implementación (runtime)

<dependency>
    <groupId>com.sun.xml.ws</groupId>
    <artifactId>jaxws-rt</artifactId>
    <version>2.3.3</version>
</dependency>

Implementación (standalone)

<dependency>
    <groupId>com.sun.xml.ws</groupId>
    <artifactId>jaxws-ri</artifactId>
    <version>2.3.2-1</version>
    <type>pom</type>
</dependency>

Java Annotation

Java EE

<dependency>
    <groupId>javax.annotation</groupId>
    <artifactId>javax.annotation-api</artifactId>
    <version>1.3.2</version>
</dependency>

Jakarta EE

<dependency>
    <groupId>jakarta.annotation</groupId>
    <artifactId>jakarta.annotation-api</artifactId>
    <version>1.3.5</version>
</dependency>

Java Transaction

Java EE

<dependency>
    <groupId>javax.transaction</groupId>
    <artifactId>javax.transaction-api</artifactId>
    <version>1.3</version>
</dependency>

Jakarta EE

<dependency>
    <groupId>jakarta.transaction</groupId>
    <artifactId>jakarta.transaction-api</artifactId>
    <version>1.3.3</version>
</dependency>

CORBA

En el caso de CORBA, existe el proyecto ORB dentro de Eclipse pero sinceramente es terreno poco explorado para mi. Solo me queda desearles buena suerte.

8. Ejecutar multiples JVMs en producción

Si todo compila, se ejecuta, los tests de regresión funcionan, podriamos decir que estamos ante una migración exitosa.

Sin embargo si nuestra empresa es una «Java Shop» es probable que tengamos varios proyectos con diversos runtimes y versiones de Java y no podamos actualizar todos al mismo tiempo por lo que suele ser una buena idea ejecutar servidores cono diversas versiones de Java instaladas.

La buena noticia es que la mayoria de distribuciones Linux ofrecen mecanismos para instalar/ejecutar diferentes versiones de JDK directamente desde el repositorio, las cuales funcionan bien una al lado de la otra.

Por ejemplo Oracle Linux ofrece OpenJDK 8, 11:

Al utilizar Oracle Hotspot mediante versiones en RPM obtendremos el mismo efecto, ya que sistemas basados en YUM suelen identificarlo como una alternativa Java:

En el caso que necesitemos un sistema «limpio» tambien es una buena idea distribuir nuestra aplicacion como un contenedor de docker, sabiendo que la mayoria de imagenes de JDK se encuentran disponibles en Docker Hub:

En el caso de Windows, mi recomendación es utilizar Docker ya que el mecanismo para tener diferentes JVM directamente en el sistema es el mismo que en desarrollo, usar archivos .bat y esperar lo mejor.