--- title: "Actualizar una aplicación Java 8 crítica a Java moderno" description: "Plan práctico para pasar una aplicación Java 8 crítica a una LTS actual: inventario de dependencias, saltos por etapas, pruebas, trampas y pruebas de carga." canonical: https://sdk.enterprises/es/insights/upgrading-legacy-java language: es --- # Actualizar una aplicación Java 8 crítica a Java moderno Actualizado: 2026-09-25 > Actualice una aplicación Java 8 crítica por etapas: haga inventario de todas las dependencias, pase primero a Java 11 y después a cada versión de soporte a largo plazo posterior, y deje que las pruebas y las pruebas de carga decidan cuándo es seguro cada paso. La mayor parte del trabajo está en las bibliotecas, las herramientas de compilación y el código que toca las partes internas del JDK, no en su lógica de negocio. ## Quedarse en Java 8 reduce sus opciones cada año Una aplicación Java 8 puede seguir funcionando durante años, y esa es la trampa. Los parches de seguridad dependen cada vez más de un contrato de soporte de pago o de una distribución que todavía los adapta a las versiones antiguas, y las grandes bibliotecas han pasado página. Spring Boot 3, por ejemplo, exige como mínimo Java 17, así que quedarse en Java 8 también congela las versiones de su framework. Las JVM más recientes también ejecutan mejor el mismo código. G1 es el recolector de basura por defecto desde Java 9, los recolectores de pausas cortas como ZGC están listos para producción y las compact strings reducen el uso de memoria en cargas con mucho texto. Los ingenieros también esperan funciones modernas del lenguaje, como los records, los bloques de texto y las expresiones switch, lo que hace más difícil encontrar personal para una base de código en Java 8. ## Empiece por inventariar todo aquello de lo que depende la aplicación La actualización del JDK en sí rara vez es lo difícil. Lo difícil es la larga lista de bibliotecas, plugins y agentes escritos para Java 8 que nunca se actualizaron. Elabore una lista completa antes de cambiar nada, y anote la versión de cada elemento. - El proveedor y la versión del JDK en cada entorno, desde los portátiles de los desarrolladores hasta producción. - Las dependencias directas y transitivas, exportadas desde el árbol de dependencias de Maven o el informe de dependencias de Gradle. - Los plugins de compilación, los generadores de código y los procesadores de anotaciones como Lombok. - El servidor de aplicaciones o el contenedor de servlets, si la aplicación se ejecuta dentro de uno. - Los agentes Java de monitorización, perfilado o seguridad, que se enganchan a fondo en la JVM. - El código que usa API internas del JDK, localizado con la herramienta jdeps y su opción jdk-internals. - Las opciones de la JVM, la configuración del recolector de basura y cualquier script que analice la salida de java -version. ## Avance de versión LTS en versión LTS en lugar de saltar Pase de Java 8 a 11, después a 17 y luego a 21 o 25. Cada salto tiene sus propias eliminaciones y cambios de comportamiento, y un salto único los mezcla todos en un fallo imposible de diagnosticar. Corregir una capa cada vez mantiene cada paso lo bastante pequeño como para revisarlo y revertirlo. Siempre que pueda, actualice las bibliotecas mientras sigue en Java 8, ya que muchas versiones recientes admiten tanto JDK antiguos como nuevos. Después, ejecute la compilación existente en la nueva JVM antes de cambiar la versión de destino de la compilación. Así separa los problemas de ejecución de los de compilación, y la opción release del compilador mantiene explícito el bytecode de destino. ## Haga de las pruebas la condición para cada paso Las pruebas son su única señal objetiva de que la aplicación actualizada se sigue comportando igual. Si los recorridos críticos tienen poca cobertura, escriba primero pruebas de caracterización: pruebas que capturan lo que hace hoy el sistema, incluidos sus casos límite extraños, sin juzgar si ese comportamiento es correcto. Añada pruebas de integración que se ejecuten contra una base de datos real y brokers de mensajería reales, porque muchos fallos de actualización solo aparecen en esas fronteras. En los sistemas con muchos cálculos, vuelva a pasar las mismas entradas por la versión antigua y por la nueva y compare los resultados campo a campo. Preste atención a las fechas, los números y el texto: Java 9 pasó a usar por defecto los datos regionales de CLDR y Java 18 convirtió UTF-8 en el juego de caracteres por defecto, y ambos cambios pueden alterar en silencio el formato o la lectura de los datos. ## Conozca las trampas que rompen el código Java 8 La mayoría de las roturas entran en unas pocas categorías conocidas. Busque cada una antes de la actualización en lugar de descubrirla en producción. - Módulos de Java EE y CORBA eliminados: Java 11 quitó del JDK JAXB, JAX-WS, JavaBeans Activation y las anotaciones comunes, así que hay que volver a añadirlos como dependencias explícitas. - Encapsulación estricta de las partes internas del JDK: el acceso reflexivo ilegal generaba avisos desde Java 9, se deniega por defecto desde Java 16 y no puede volver a activarse de forma global desde Java 17. Corríjalo actualizando la biblioteca; use add-opens solo como excepción temporal y documentada. - Herramientas de bytecode desactualizadas: las versiones antiguas de Lombok, Mockito, Byte Buddy, ASM y de los plugins de compilación fallan con las versiones de archivo de clase más recientes. - Funciones eliminadas: el motor JavaScript Nashorn se eliminó en Java 15, y el Security Manager quedó obsoleto en Java 17 y se desactivó definitivamente en Java 24. - Opciones de la JVM eliminadas: el recolector de basura CMS se eliminó en Java 14, y una JVM arrancada con opciones eliminadas puede negarse a iniciarse. ## Demuestre el rendimiento con una carga realista, no en un portátil Un nuevo JDK cambia el recolector de basura, el compilador JIT y la disposición de la memoria, así que el rendimiento puede moverse en cualquier dirección. Ejecute una prueba de carga que reproduzca el perfil de tráfico de producción, en el mismo hardware o tipo de instancia, antes y después de cada paso. Compare los percentiles de latencia, el caudal de procesamiento, la memoria y las pausas del recolector de basura, y deje que el JIT se caliente antes de medir. Nuestros ingenieros dirigieron la migración de Java 8 a 16 de una aplicación crítica de trading intradía de gas para una mesa nacional de negociación de gas, a través de Sopra Steria. En ese sistema, los cálculos de capacidad y de flujos de energía tenían que seguir siendo correctos y rápidos bajo una carga de alta frecuencia, así que la actualización fue acompañada de un trabajo de optimización de esos cálculos y se validó bajo carga en lugar de darse por supuesta. ## Despliegue de forma gradual y conserve una vía de vuelta atrás Lleve primero el entorno de ejecución actualizado a una sola instancia o a una pequeña parte del tráfico, y vigile la tasa de errores, la latencia y el comportamiento del recolector de basura frente a la referencia de Java 8. Mantenga desplegable la compilación anterior hasta que la nueva versión haya pasado por los ciclos normales del negocio, incluidos los cierres de mes o los periodos de máxima actividad. Solo entonces elimine los artefactos de Java 8 y empiece a usar las nuevas funciones del lenguaje. Si quiere ayuda para planificar o llevar a cabo una actualización como esta, SDK Enterprises la realiza con ingenieros propios y especialistas seleccionados, bajo un único contrato del que responde. ## Puntos clave - El esfuerzo de una actualización de Java 8 está sobre todo en las dependencias, las herramientas de compilación y el uso de las partes internas del JDK, no en la lógica de negocio. - Avance de una versión LTS a la siguiente, de una en una, para que cada fallo tenga una sola causa localizable. - Las pruebas de caracterización y de integración son la condición para cada paso, sobre todo en fechas, números y codificación de texto. - Valide el rendimiento con una carga similar a la de producción, porque los cambios en el recolector de basura y el JIT pueden mover los resultados en cualquier dirección. - Despliegue primero en una pequeña parte del tráfico y mantenga desplegable la compilación de Java 8 hasta que el nuevo entorno de ejecución haya demostrado su fiabilidad. ## Preguntas frecuentes ### ¿Puedo pasar directamente de Java 8 a Java 21? Puede, pero hereda de golpe todos los cambios de Java 9 a 21, lo que hace difícil rastrear los fallos. Pasar por 11 y 17 cuesta un poco más de tiempo de compilación y ahorra mucha depuración en un sistema crítico. ### ¿Cuánto se tarda en actualizar una aplicación Java 8? Depende del número de dependencias, de cuántas usan partes internas del JDK, de la cobertura de pruebas y de cuántas pruebas de carga necesite el sistema. Un inventario y una ejecución de prueba en la nueva JVM le dan pronto una estimación realista, antes de comprometerse con un calendario. ### ¿Hay que reescribir código para usar las nuevas funciones de Java? No. Java mantiene una fuerte compatibilidad con versiones anteriores para el código que se ciñe a las API estándar no obsoletas. Adopte los records, los bloques de texto y otras funciones de forma gradual, una vez que el entorno de ejecución actualizado sea estable en producción. ## Servicios relacionados - [Software a medida](https://sdk.enterprises/es/services/product-engineering) - [Seguridad de aplicaciones](https://sdk.enterprises/es/services/secure-systems)