Muchas organizaciones a punto de migrar desde Oracle Java SE se preguntarán cuánto tiempo llevará el proceso. Sin embargo, no existe una respuesta única para esa pregunta. El tiempo necesario para una migración depende de al menos media docena de variables específicas de una organización.
Una de esas variables son los objetivos de migración de una empresa: algunos objetivos tardan más en alcanzarse que otros. Por ejemplo, si el objetivo es realizar una transición completa desde Oracle Java lo más rápido posible, el plan de migración será diferente al de una organización que busca principalmente soporte para aplicaciones heredadas que ejecutan versiones anteriores de Java, como Java 6 y 7, y preferiría un enfoque gradual a lo largo de un período más largo.
Preparándose para migrar desde Oracle Java SE
La primera etapa de una migración es realizar un inventario de Java, que suele ser la parte que consume más tiempo de una migración del Kit de desarrollo de Java (JDK) debido a la variedad de versiones de JDK en uso. Normalmente, cuando se implementa una nueva aplicación, utiliza la última versión del JDK en ese momento y continúa usándola incluso cuando se lanzan versiones más nuevas de Java. Esto es bastante lógico porque se ha probado con la versión implementada.
Suponiendo que la aplicación funcione sin problemas, no es necesario actualizar su versión JDK. Se requiere una actualización solo cuando los parches de seguridad y las correcciones de errores ya no están disponibles para la versión en uso y existen inquietudes sobre el rendimiento de la aplicación o una vulnerabilidad de seguridad conocida que debe abordarse.
Para crear un inventario de uso de JDK completo, las organizaciones deben examinar cada máquina de su patrimonio que ejecute cualquier aplicación basada en máquina virtual Java (JVM). Esto puede resultar sencillo si se utilizan herramientas de gestión de activos de TI (ITAM) para monitorear el uso del software. Muchas empresas implementan estas herramientas para garantizar el cumplimiento de los términos y condiciones de la licencia. Estas herramientas pueden producir rápidamente un informe que muestra qué máquinas tienen qué versiones de Java instaladas. También hay scripts disponibles de proveedores como Azul para ayudar a inventariar las JVM sin problemas.
A continuación, la organización debe empezar a pensar en los problemas potenciales que pueden surgir en función de lo que se encontró durante el inventario.
Por ejemplo, es muy común que los usuarios compren aplicaciones en lugar de desarrollarlas. No tener que desarrollar y mantener software personalizado internamente puede resultar muy rentable. Muchas de estas aplicaciones que utilizan Java especificarán una versión requerida del JDK e incluso posiblemente un nivel mínimo de actualización de la versión; esto no es diferente de la forma en que otras aplicaciones especifican una versión mínima de Windows o Linux.
El usuario debe obtener el JDK y ponerlo a disposición de la aplicación. Los proveedores de aplicaciones suelen indicar en su documentación que admitirán la aplicación sólo si se utiliza con el JDK correcto. Esto es sensato para el desarrollador de aplicaciones porque puede ayudar a eliminar los problemas causados por el uso de tiempos de ejecución de Java obsoletos o inapropiados. Debido a que Oracle JDK ha sido tan omnipresente en el pasado, muchos proveedores de aplicaciones han declarado que solo Oracle JDK calificará para recibir soporte.
Sin embargo, los cambios recientes en las licencias y precios de Oracle JDK significan que los usuarios exigen cada vez más soporte cuando ejecutan JDK alternativos. Muchos proveedores de aplicaciones ahora brindarán soporte siempre que la aplicación se ejecute en una versión de OpenJDK certificada por el kit de compatibilidad tecnológica (TCK). Como pueden confiar en que dichas distribuciones serán funcionalmente idénticas al JDK de Oracle, no necesitan preocuparse por probar múltiples distribuciones con sus aplicaciones.
A veces, una aplicación indicará que ciertas distribuciones de OpenJDK son válidas para recibir soporte, pero no la que una organización desea utilizar. En este caso, los usuarios deben comunicarse con el proveedor de la aplicación para agregar la distribución requerida a su lista. Siempre que se pruebe TCK, el proveedor no debería tener objeciones.
En cualquier organización grande donde se utilizan varias aplicaciones Java, las aplicaciones tendrán propietarios diferentes. Al planificar una migración exitosa, es esencial incluir a todas las partes interesadas, es decir, todos los propietarios de las aplicaciones que deben utilizar el nuevo tiempo de ejecución de Java y/o están preocupados por el estado de sus aplicaciones.
Migrando a OpenJDK
Las distribuciones de OpenJDK no admiten parches in situ para las actualizaciones: aplicar una actualización al JDK requiere instalar un JDK completamente nuevo. Esto significa que el proceso de instalación de la migración se puede tratar exactamente como implementar una nueva actualización, excepto que instala la actualización de Zulu JDK en lugar de la actualización de Oracle JDK.
A menos que haya un error específico que cause problemas de estabilidad de la aplicación, los usuarios no verán ninguna necesidad urgente de pasar a una nueva versión de Java, incluso si están usando una versión bastante antigua. Sin embargo, desde un punto de vista administrativo, siempre es una buena idea instalar la última actualización al migrar a una nueva distribución OpenJDK para mantener el más alto nivel de seguridad para las aplicaciones.
En la gran mayoría de los casos, el proceso de actualización es sencillo y sin problemas. Sin embargo, a veces una actualización incluye cambios que pueden cambiar el comportamiento de una aplicación.
Un ejemplo de Tomcat
Veamos un ejemplo que utiliza el motor de servlet Apache Tomcat, muy utilizado. Supongamos que tenemos Tomcat 8 ejecutándose en Oracle JDK 8u202. Esta no es la versión más reciente de Tomcat, pero funciona perfectamente para nuestra aplicación, por lo que no se ha actualizado. Tenemos un servlet en ejecución que toma datos del cliente, realiza una consulta en una base de datos MySQL y devuelve un resultado.
Para nuestra migración, instalamos Zulu 8 actualización 372 y reiniciamos el servidor. Sin embargo, cuando intentamos utilizar la aplicación, recibimos un mensaje de error que nos indica que hubo un error en el enlace de comunicación. Esto no tiene nada que ver con cambiar de Oracle a Zulu.
En cambio, es el resultado de un cambio realizado en la actualización 291 de JDK 8 de octubre de 2021. En esta actualización, la configuración predeterminada de Transport Layer Security (TLS) se cambió para deshabilitar TLSv1.0 y TLSv1.1 de forma predeterminada. Por lo tanto, para que la aplicación funcione como antes, debemos modificar el archivo jre/lib/security/java.security y eliminar las referencias TLS de la configuración de algoritmos jdk.tls.disabled.
Cuando ocurre algo así, es importante verificar que el problema se debe al uso de una actualización diferente del JDK en lugar de una distribución diferente. Tener un proveedor de soporte comercial que pueda proporcionar actualizaciones anteriores puede resultar extremadamente beneficioso en tales casos. Simplemente instale el mismo nivel de actualización de JDK y luego vuelva a probar la aplicación. En nuestro caso de ejemplo, el equipo de soporte de Azul podría proporcionar detalles de los cambios de configuración necesarios para resolver el problema.
Después de instalar el nuevo JDK, debemos realizar los cambios necesarios para cambiar las aplicaciones y utilizarlo. Por ejemplo, puede que sea necesario cambiar la variable de entorno JAVA_HOME y los lanzadores utilizados para aplicaciones individuales, como el motor de servlet Tomcat. La opción más segura es cambiar esta variable de entorno en todas las máquinas migradas.
Después de la instalación, debemos probar todas las aplicaciones que se han cambiado al nuevo JDK para garantizar un funcionamiento correcto. Los usuarios probablemente no observarán ningún comportamiento diferente a menos que se hayan producido cambios entre actualizaciones.
Pruebas para verificar el comportamiento correcto.
El proceso de prueba variará mucho dependiendo de cada aplicación. Las aplicaciones desarrolladas internamente pueden tener pruebas de regresión exhaustivas que pueden ejercitar completamente todas las partes de la aplicación para verificar el comportamiento correcto.
Las aplicaciones de terceros (ya sean de código abierto o comerciales) pueden tener un conjunto de pruebas estándar que se pueden ejecutar. De lo contrario, un usuario experimentado debería ejecutar la aplicación y probar tantos aspectos funcionales como sea posible.
Una vez que todas las pruebas hayan pasado a satisfacción de cada usuario, la migración estará completa. La organización ahora estará en una posición sólida para mantener su patrimonio Java con los niveles más altos de seguridad y estabilidad, a menudo más que antes. Además, tendrá una idea clara de dónde se utiliza el tiempo de ejecución de Java y más experiencia en la actualización de máquinas a la última actualización de Java.
Este artículo está basado en un extracto de Migración OpenJDK para principiantes, edición especial Azulpor el campeón de Java Simon Ritter.