Retos técnicos
Situaciones que se repiten en aplicaciones empresariales con años encima. Cada una explica qué se analiza antes de tocar nada y qué suele salir mal cuando no se hace.
Son páginas para entender el problema. Si ya lo tienes claro y lo que buscas es quién lo ejecute, están los servicios.
Evolución de aplicaciones Java EE hacia Jakarta EE, analizando compatibilidad, dependencias y servidores.
Ver reto →Java LegacyQué se analiza antes de modernizar: inventario, deuda técnica, riesgos y por dónde empezar.
Ver reto →Spring BootEvolución de aplicaciones Java hacia Spring Boot y arquitecturas backend más actuales.
Ver reto →Versiones JavaAnálisis de compatibilidad y evolución hacia versiones más actuales de Java.
Ver reto →¿Tu caso se parece a alguno de estos?
Cuéntame el problemaCada uno es el síntoma visible de un problema de fondo distinto. Aquí está la causa en una línea; el desarrollo, en la página que corresponde.
NoClassDefFoundError: javax/xml/bind/JAXBContextCausa: JAXB dejó de venir en el JDK a partir de Java 11 y no hay implementación que cargar en ejecución.
Qué se hace: Es un síntoma de un cambio de versión del JDK: qué arrastra actualizar la versión de Java.
package javax.persistence does not existCausa: El proyecto ya usa dependencias jakarta pero quedan importaciones sin convertir, o al revés.
Qué se hace: Es el cambio de espacio de nombres: cómo se migra de Java EE a Jakarta EE.
InaccessibleObjectException: module java.base does not opens java.langCausa: Una librería accede por reflexión a clases internas del JDK, y desde Java 16 eso es un error y no un aviso.
Qué se hace: Sale al subir de versión y se resuelve actualizando la librería: actualización de versiones de Java.
ClassNotFoundException: javax.servlet.Filter al arrancar SpringCausa: La aplicación corre sobre Spring 6, que ya es jakarta, con alguna dependencia todavía en la variante antigua.
Qué se hace: Es el salto de Spring Boot 2 a 3: qué implica la migración hacia Spring Boot.
UnsupportedClassVersionError: class file version 61.0Causa: El entorno que ejecuta la aplicación usa un JDK más antiguo que el que la compiló.
Qué se hace: Casi siempre indica que el servidor marca el techo real: qué se analiza antes de modernizar.
Los síntomas que llegan a una reunión rara vez se describen en términos técnicos. Esta es la traducción.
| Lo que se dice en la reunión | Lo que suele ser | Dónde se explica |
|---|---|---|
| No podemos actualizar esa librería | La versión de Java se quedó atrás y ya no hay versiones compatibles | Actualización de versiones Java |
| El proveedor se fue y nadie toca ese módulo | No hay pruebas ni documentación, así que ningún cambio es verificable | Java Legacy |
| Cada despliegue ocupa un fin de semana | Problema de arquitectura y de pruebas, no de despliegue | Java Legacy |
| Queremos microservicios | Casi siempre es necesidad de desplegar por partes, que se resuelve antes | Migración a Spring Boot |
| Hay que certificar el servidor y ya no da soporte | El salto de espacio de nombres viene incluido en el cambio | Java EE a Jakarta EE |
Es lo más habitual, y el orden importa: invertirlo obliga a repetir trabajo ya hecho.
Antes de mover una versión hay que poder demostrar que el comportamiento se mantiene. Sin esa red, todo lo que viene después es adivinar.
Condiciona todo lo demás: el servidor que se puede usar, las versiones de framework disponibles y qué dependencias siguen publicando. Es el techo real del proyecto.
El paso de javax a jakarta afecta al artefacto entero y no admite estados intermedios, así que conviene hacerlo cuando la versión de Java ya está decidida.
Spring Boot 3 exige las dos cosas anteriores resueltas. Intentarlo antes obliga a deshacer y rehacer la mitad del trabajo.
A veces el inventario sale limpio: la versión es reciente, las dependencias están al día y el código es razonable. Y aun así nadie se atreve a desplegar un viernes.
En esos casos lo que falta no es una migración, sino saber qué hace el sistema. Puede ser que no haya nadie que conozca las reglas de negocio, que no exista un responsable funcional a quien preguntar, o que las pruebas ejecuten código sin comprobar comportamiento.
Eso no se arregla subiendo de versión, y conviene detectarlo antes de presupuestar una modernización que no resolvería el problema real.
Preguntas frecuentes
Por el que bloquee al resto, que casi siempre es la versión de Java. El análisis inicial sirve precisamente para ordenarlos por impacto en lugar de por urgencia percibida.
Es mejor no hacerlo. Cuando fallan dos cambios simultáneos no hay forma de saber cuál lo provocó, y el tiempo que se ahorra en calendario se pierde depurando.
No, si cada fase se despliega. Una rama de migración abierta durante meses acaba en un conflicto que nadie se atreve a resolver, y ese es el escenario que se evita.
Es el punto de partida más frecuente. La información sale del código, del historial del repositorio y de lo que se observa en producción: que nadie recuerde por qué se tomó una decisión no impide ver qué hace hoy el sistema.