Señales de que ha llegado el momento

  • La aplicación sigue en Java 8 u 11, y un JDK más reciente rompe la compilación.
  • Depende de Spring Boot 2, Karaf/OSGi o un servidor de aplicaciones que nadie quiere tocar.
  • Los escáneres de seguridad señalan bibliotecas que no se pueden actualizar sin actualizar todo lo demás.
  • Un desarrollador nuevo tarda días en poner el proyecto en marcha en local.

Lo que suele tener que cambiar

  • JAXB, JAX-WS y otros módulos eliminados del JDK vuelven como dependencias explícitas.
  • El espacio de nombres javax.* pasa a ser jakarta.* con Spring Boot 3 y el Jakarta EE actual.
  • Los plugins de compilación, las bibliotecas de pruebas y las herramientas de bytecode necesitan versiones compatibles con Java 21.
  • El código y las bibliotecas que acceden a elementos internos del JDK por reflexión deben sustituirse o recibir acceso explícito.

Cómo lo abordo

  • Primero, el inventario. Identifico los módulos, las dependencias y las suposiciones sobre el entorno, y anoto qué partes tienen pruebas y cuáles no.
  • Una compilación reproducible. Antes de cualquier actualización, el proyecto tiene que compilarse y ejecutarse igual en cualquier máquina y en el pipeline.
  • Actualización por etapas. Las dependencias, los frameworks y el JDK avanzan en pasos desplegables, no en una rama larga que nunca se integra.
  • Pruebas donde está el riesgo. Añado pruebas alrededor del código que más toca la actualización, en lugar de perseguir un porcentaje de cobertura.
  • El desarrollo continúa. Las nuevas funciones y las correcciones siguen durante la migración. En SIB-BW2 avanzan en paralelo.

Proyecto actual: SIB-BW2

SIB-BW2 gestiona infraestructura vial para una administración regional alemana. Trabajo en su paso de Java 8/Karaf a Java 21/Spring Boot, desarrollé unos 30 de sus informes y la herramienta de migración que traslada miles de estructuras (Bauwerke) al estándar ASB-ING cuando hace falta.

Qué recibe

  • Un inventario por escrito del entorno, las dependencias y los riesgos, con un orden de actualización
  • La aplicación actualizada, desplegada por etapas
  • Pruebas alrededor del código que cambió la actualización
  • Documentación de los cambios y de cómo compilar, ejecutar y publicar la aplicación

Cuándo no lo recomendaría

  • La aplicación se va a sustituir de todos modos en menos de un año.
  • Es tan pequeña que reconstruirla sobre una base actual cuesta menos que actualizarla.

Preguntas sobre la actualización de Java

¿Tenemos que pasar primero por Java 11 y 17?
No necesariamente. El JDK a menudo puede pasar directamente a 21, pero las bibliotecas y los frameworks suelen avanzar por etapas porque cada uno trae sus propios cambios incompatibles. El inventario decide el orden.
¿Necesitamos Spring Boot 3?
Si la aplicación usa Spring Boot 2, sí, tarde o temprano: la versión 2 ya no recibe actualizaciones de código abierto. Spring Boot 3 requiere Java 17 o posterior y el espacio de nombres jakarta.*, así que suele formar parte del mismo proyecto.
¿Puede seguir usándose el sistema durante la migración?
Sí. Para eso se actualiza por etapas. Cada etapa se despliega y se comprueba antes de empezar la siguiente.
¿Y las aplicaciones sobre Karaf/OSGi o un servidor de aplicaciones?
Necesitan un paso más: pasar a un entorno que los frameworks actuales admitan, normalmente Spring Boot con un servidor integrado. Es el cambio que estoy haciendo en SIB-BW2.

¿Tiene un problema de proceso o software que merece la pena revisar?

Una breve conversación basta para decidir si el siguiente paso adecuado es una auditoría, una pequeña implementación o no desarrollar software a medida.