Lenguajes de Programación

Java 22 hoy: una versión no-LTS ya superada

Java 22 se publicó en marzo de 2024 como una de las versiones semestrales del JDK. Su función era incorporar nuevas capacidades y hacer avanzar la plataforma, no ofrecer un ciclo prolongado de mantenimiento. Esa diferencia importa especialmente para cualquier proyecto que todavía la utilice: Java 22 no es LTS y Oracle considera que una versión no-LTS queda superada cuando se publica la siguiente feature release.

A 9 de septiembre de 2026, JDK 26 es la versión más reciente publicada y Java 25 es la LTS más reciente. Esto no invalida lo que incorporó Java 22, pero cambia la pregunta para quien todavía lo utiliza. Ya no se trata de decidir si merece la pena adoptar sus novedades, sino de comprobar qué dependencia mantiene al proyecto en esa versión y si existe una estrategia razonable para salir de ella.

Dónde encaja Java 22 en el ciclo semestral de Java

Java sigue un ciclo de nuevas versiones cada seis meses. Dentro de ese esquema, Oracle reserva la consideración LTS para determinadas releases que reciben un horizonte de soporte más amplio. Java 21 y Java 25 son LTS, mientras que Java 22, 23 y 24 forman parte del grupo de versiones no-LTS.

En la hoja de ruta de soporte de Java SE de Oracle, Java 22 aparece dentro del tramo no-LTS 22-24 y sin Extended Support. Además, Oracle establece que una release no-LTS se considera superada cuando llega la siguiente. En el caso de Java 22, ese punto llegó con Java 23 en septiembre de 2024.

Conviene no convertir esa política en una afirmación universal sobre cualquier distribución del JDK. El soporte efectivo también depende del proveedor y de la distribución utilizados por la organización. Por eso, antes de decidir hay que comprobar tanto el ciclo de Java SE como las condiciones concretas del runtime desplegado.

Qué implica mantener un proyecto en Java 22

¿Hay que migrar inmediatamente cualquier aplicación que siga en Java 22? No necesariamente. Un entorno de desarrollo, una prueba controlada o un sistema pendiente de validar una dependencia pueden justificar una permanencia temporal. Lo importante es que sea una decisión explícita y limitada, no una consecuencia de la inercia.

El riesgo aumenta cuando Java 22 permanece en producción sin una política clara de soporte, cuando el proveedor utilizado ya no ofrece las actualizaciones necesarias o cuando frameworks y librerías avanzan hacia JDK posteriores. También puede crecer el coste de la futura transición si el equipo acumula varias versiones intermedias sin comprobar compatibilidad.

Por tanto, saber que Java 22 es no-LTS no basta para decidir. Hay que combinar esa situación con la distribución utilizada, las dependencias del proyecto, los requisitos de soporte y el destino previsto de la aplicación. Esa evaluación será la que determine si conviene mantenerlo temporalmente o preparar la migración.

Novedades de Java 22 que siguen siendo relevantes

JDK 22 incorporó 12 JEP, pero no todas tenían el mismo grado de madurez. Esa distinción es esencial para interpretar correctamente la versión: cuatro llegaron como funcionalidades finales, siete se publicaron como preview y una permanecía en incubación.

Para un proyecto que todavía utiliza Java 22, el estado original de cada característica importa porque determina qué podía utilizarse como parte estable de la plataforma y qué requería asumir una API o sintaxis todavía sujeta a cambios. Las release notes oficiales de JDK 22 permiten reconstruir esa separación sin tratar todas las novedades como equivalentes.

Qué llegó como funcionalidad final en JDK 22

Entre las incorporaciones finalizadas de Java 22 destacan cuatro cambios con funciones muy distintas:

• La Foreign Function & Memory API (JEP 454) quedó finalizada después de varias rondas de preview. Permite interoperar con código y memoria externos a la JVM mediante una API orientada a sustituir muchos usos tradicionales de JNI.
• Con Unnamed Variables & Patterns (JEP 456), el carácter _ puede expresar que una variable o un patrón requerido por la sintaxis no va a utilizarse.
• Java 22 incorporó el lanzamiento de programas multifichero desde código fuente (JEP 458), facilitando ejecutar pequeños proyectos sin introducir inmediatamente un proceso de compilación con un build tool.
• Region Pinning for G1 (JEP 423) reduce el impacto que podían tener determinadas regiones críticas JNI sobre el funcionamiento del recolector G1.

Que estas JEP fueran finales en JDK 22 no significa que todo proyecto deba utilizarlas. Sí significa que, al analizar código escrito específicamente para esa versión, no deben confundirse con características experimentales que exigían condiciones adicionales.

Qué permanecía en preview o incubator y por qué importa

Siete JEP seguían en preview: Statements before super(...), Class-File API, String Templates, Stream Gatherers, Structured Concurrency, Implicitly Declared Classes and Instance Main Methods y Scoped Values. La Vector API (JEP 460) permanecía además en su séptima fase de incubación.

Una preview está suficientemente especificada e implementada para probarse, pero todavía puede cambiar o desaparecer antes de convertirse en parte permanente de Java. Su utilización requiere habilitar las preview features durante compilación y ejecución. Una API incubator tiene todavía un carácter más experimental y se distribuye en módulos específicos fuera de las APIs finales.

Esta diferencia tiene una consecuencia práctica: si un proyecto Java 22 utiliza alguna de estas características, la migración debe revisar su evolución concreta en la versión de destino. No basta con comprobar que el código compila, porque nombres, APIs, comportamiento o incluso la continuidad de una feature pueden haber cambiado entre releases.

¿Seguir en Java 22 o migrar a una versión LTS?

Que Java 22 sea una versión no-LTS no implica que todos los proyectos deban abandonarla de inmediato. La decisión depende de qué soporte necesita la aplicación, qué dependencias condicionan el cambio y qué versión admite realmente el entorno completo. Migrar por calendario sin comprobar esos factores puede introducir incidencias que una transición planificada habría detectado antes.

El objetivo debería ser distinguir entre una permanencia temporal justificada y una situación en la que Java 22 se mantiene únicamente por inercia. Si el proyecto necesita estabilidad a largo plazo y no existe un bloqueo técnico relevante, una versión LTS como Java 25 ofrece un destino más coherente que ir saltando entre releases semestrales no-LTS.

Qué revisar antes de decidir: soporte, dependencias, framework y tooling

La versión del JDK es solo una parte del sistema. Antes de fijar destino y calendario conviene revisar varios puntos:

• El soporte requerido depende de la distribución utilizada, las condiciones del proveedor y las exigencias internas del proyecto.
• Las librerías de terceros pueden convertirse en el principal bloqueo de compatibilidad, incluso cuando el código propio necesita pocos cambios.
• Hay que comprobar qué versiones del JDK admite oficialmente el framework utilizado y si el salto obliga a actualizarlo previamente.
• Maven, Gradle, plugins, analizadores, agentes y otras piezas de tooling también deben formar parte de la validación.
• La política tecnológica de la organización puede exigir una versión LTS aprobada, reduciendo el margen para permanecer sobre Java 22.
• Antes de asumir que todo funciona, las pruebas de regresión deben confirmar no solo que la aplicación arranca, sino que mantiene el comportamiento esperado.

Una dependencia incompatible no siempre justifica abandonar la migración. Puede indicar que primero hay que actualizarla, sustituirla o esperar a una versión compatible. Lo importante es que el bloqueo quede identificado y tenga una decisión asociada.

Cómo validar la transición sin asumir compatibilidad

La guía de migración de Oracle para JDK 25 plantea la migración como un proceso iterativo. Entre sus recomendaciones está probar primero la aplicación sobre el nuevo JDK, revisar librerías de terceros, recompilar cuando sea necesario y utilizar herramientas como jdeps para detectar dependencias sobre APIs internas o módulos.

Que una aplicación arranque tampoco demuestra por sí solo que la transición esté terminada. Hay que revisar warnings, opciones de JVM obsoletas o eliminadas y, sobre todo, ejecutar las pruebas suficientes para detectar cambios de comportamiento que no aparecen como errores de compilación.

Si la aplicación forma parte de un sistema amplio o arrastra dependencias históricas, conviene tratar la transición como una migración controlada. Los criterios para reducir el riesgo en una migración de sistemas legacy resultan especialmente útiles cuando hay integraciones, entornos paralelos o necesidad de reversión.

Tabla de decisión según la situación del proyecto

La decisión puede resumirse según el contexto real del proyecto:

Situación del proyecto	Riesgo principal	Acción recomendada
Prueba local, laboratorio o desarrollo temporal sobre Java 22	Bajo si el entorno está aislado y no exige soporte prolongado	Puede mantenerse temporalmente, documentando que no es la versión objetivo a largo plazo
Aplicación en producción sobre Java 22 sin bloqueos conocidos	Permanecer en una release no-LTS y acumular distancia respecto a versiones mantenidas	Planificar la migración y validar una LTS compatible con el stack
Una dependencia crítica todavía no admite la versión de destino	Actualizar el JDK puede romper una pieza esencial de la aplicación	Resolver o aislar la dependencia antes del cambio y definir un plazo para volver a evaluar
Framework o tooling requieren actualización previa	Introducir varios cambios simultáneos aumenta la dificultad para localizar errores	Separar las actualizaciones cuando sea posible y validar cada paso
La organización exige versiones LTS	Java 22 no cumple la política tecnológica definida	Priorizar una LTS aprobada y tratar cualquier permanencia en Java 22 como una excepción temporal

La clave no es decidir entre “migrar” o “no migrar” de forma abstracta. Es saber qué impide migrar, qué riesgo introduce quedarse y qué comprobaciones permiten avanzar con suficiente control.

Conclusiones

Java 22 aportó cambios relevantes al lenguaje y a la plataforma, pero hoy debe entenderse en su contexto: fue una release no-LTS y muchas de sus novedades todavía estaban en preview o incubator. Para un proyecto que sigue utilizándola, esa diferencia importa tanto como las funcionalidades concretas que incorporó.

Permanecer temporalmente en Java 22 puede ser razonable cuando existen dependencias, restricciones de framework o validaciones pendientes. Lo importante es que esa permanencia responda a una decisión técnica y tenga un horizonte definido, no a la inercia.

Si el proyecto necesita soporte prolongado y el stack ya permite avanzar, la opción más sólida es preparar una migración controlada hacia una versión LTS compatible. Antes de cambiar el JDK conviene validar dependencias, tooling, pruebas y políticas internas para que la transición reduzca riesgo en lugar de trasladarlo a producción.