Versiones de Java: cuál es la última y cuáles son LTS

La última versión de Java es Java 27, publicada el 15 de septiembre de 2026, y la última LTS es Java 25. Las versiones LTS de Java son 8, 11, 17, 21 y 25; la siguiente será Java 29, prevista para septiembre de 2027. Para producción, la referencia es la LTS, no la última.

Esa es la respuesta corta, y sirve para casi todo. Lo que no suele contar nadie es lo que hay debajo: «LTS» no significa lo mismo en cada proveedor, una misma versión deja de ser gratuita en fechas distintas según qué JDK hayas instalado, y desde el 20 de octubre de 2026 un equipo con Oracle JDK 21 puede cambiar de licencia con solo aplicar un parche.

Aquí tienes la tabla completa, cómo leerla y qué versión elegir según tu caso. Todas las fechas salen de fuentes oficiales, enlazadas al final y consultadas el 5 de noviembre de 2026. Las he contrastado una a una porque en este tema circulan muchas tablas caducadas.

Tabla de versiones de Java: fechas, LTS y soporte gratuito

Versión	Publicada	¿LTS?	Temurin, gratis al menos hasta	Oracle JDK, gratis en producción hasta	Spring Boot
Java 29	septiembre 2027 (previsto)	Sí (prevista)	—	septiembre 2030 (previsto)	—
Java 28	9 marzo 2027 (previsto)	No	—	septiembre 2027 (previsto)	—
Java 27 (la última)	15 septiembre 2026	No	marzo 2027	marzo 2027	4.0 y 4.1
Java 26	17 marzo 2026	No	terminado (septiembre 2026)	terminado (septiembre 2026)	4.0 y 4.1
Java 25 (última LTS)	16 septiembre 2025	Sí	septiembre 2031	septiembre 2028	3.5, 4.0 y 4.1
Java 22 a 24	2024 – 2025	No	terminado	terminado	según versión (ver abajo)
Java 21	19 septiembre 2023	Sí	diciembre 2029	terminado (hasta 21.0.12)	2.7 a 4.1
Java 18 a 20	2022 – 2023	No	terminado	terminado	—
Java 17	14 septiembre 2021	Sí	octubre 2027	terminado (hasta 17.0.12)	2.7 a 4.1; mínimo de 3.x y 4.x
Java 11	25 septiembre 2018	Sí	octubre 2027	nunca lo fue	2.7 como máximo
Java 8	marzo 2014	Sí	diciembre 2030	terminado (abril 2019)	2.7 como máximo

La columna de Spring Boot indica las líneas que declaran compatibilidad con esa versión de Java en su último parche.

Cuatro lecturas de la tabla:

• La última versión de Java no es la que deberías poner en producción. Java 27 deja de actualizarse en marzo de 2027. Si la adoptas, te comprometes a saltar a Java 28 en cuanto salga, y a la 29 seis meses después.
• Java 8 sobrevive a Java 11 y a Java 17 en Temurin. Parece una errata y no lo es: Adoptium publica binarios mientras el código fuente se siga manteniendo, y el de Java 8 sigue vivo. Eso no la convierte en una buena opción.
• Java 11 y Java 17 son las LTS con menos margen: en Temurin tienen garantizado menos de un año, y los parches de Oracle JDK 17 dejaron de ser gratuitos hace dos.
• Las fechas de Temurin son «al menos», y las de Oracle a futuro, planes. Oracle avisa de que las versiones todavía no publicadas pueden cambiar.

Si solo vienes a por las novedades de una versión concreta, tengo una guía aparte de Java 25: novedades, instalación y migración desde Java 21. Aquí hablamos del calendario.

Cuál es la última versión de Java en noviembre de 2026

Depende de qué entiendas por «última», y por eso la pregunta confunde tanto:

• Última versión de Java publicada: Java 27, del 15 de septiembre de 2026.
• Última versión LTS de Java: Java 25, del 16 de septiembre de 2025.
• Último parche de cada versión: a 5 de noviembre de 2026, Temurin va por 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.33 y 8u512 (Java 8 va por plataformas: 8u512 en Linux y Windows x64, 8u504 en macOS x64).
• En desarrollo: Java 28, en builds de acceso anticipado.

El dato que de verdad importa en producción es el tercero. Tener «Java 25» no es lo mismo que tener Java 25 al día: la versión 25.0.0 de septiembre de 2025 lleva más de un año de parches de seguridad acumulados. El ritmo es de una actualización cada tres meses, normalmente el tercer martes de enero, abril, julio y octubre, más alguna extraordinaria.

Si has llegado aquí porque un programa te pide Java en tu ordenador, y no porque desarrolles, la respuesta es otra: instala la versión que te pida ese programa. Oracle sigue ofreciendo actualizaciones gratuitas de Java 8 para uso personal en java.com, y muchas aplicaciones de escritorio siguen dependiendo de ella.

Cuáles son las versiones LTS de Java y qué significa LTS

Las versiones LTS de Java son 8, 11, 17, 21 y 25. LTS significa Long-Term Support, soporte a largo plazo: alguien se compromete a seguir publicando parches de seguridad y corrección durante años. Las versiones que no son LTS se actualizan solo seis meses, hasta que sale la siguiente.

LTS lo decide cada proveedor, no OpenJDK

Este es el malentendido más extendido. OpenJDK no publica versiones LTS: publica una versión cada seis meses, todas con el mismo proceso y la misma calidad. La propia especificación de versiones, la JEP 322, habla de series para las que «un implementador ofrece soporte a largo plazo». Es decir, LTS es un compromiso del proveedor, no un atributo de la versión.

Se ve en la práctica. Esto es lo que imprime un Temurin de Java 25:

$ java --version
openjdk 25 2025-09-16 LTS
OpenJDK Runtime Environment Temurin-25+36 (build 25+36-LTS)
OpenJDK 64-Bit Server VM Temurin-25+36 (build 25+36-LTS, mixed mode, sharing)

Ese LTS es una etiqueta que pone quien compila el JDK. Los proveedores se han alineado en las mismas versiones, y por eso se habla de «Java 21 LTS» como si fuera algo universal. Pero el compromiso, y sobre todo su fecha de fin, es de cada uno. De ahí que Java 21 acabe en diciembre de 2029 en Temurin y que el soporte de pago de Oracle llegue a septiembre de 2031.

Una LTS cada dos años, una versión cada seis meses

El calendario actual tiene dos ritmos:

• Cada seis meses, en marzo y septiembre, sale una versión nueva.
• Cada dos años, una de ellas es LTS: 17, 21, 25 y, según los planes de Oracle, 29 y 33. Antes el salto era mayor: entre Java 11 y Java 17 pasaron tres años.

Adoptium lo formula igual: cada dos años desde 2021 una versión se designa LTS, y se compromete a mantenerla al menos cuatro años.

Las versiones no LTS no son betas

Otro error frecuente. Java 26 y Java 27 son versiones finales, con la misma exigencia que una LTS. La diferencia no es de calidad sino de duración del compromiso. Si tu equipo despliega con frecuencia, tiene buena cobertura de tests y puede actualizar el JDK cada seis meses, una versión no LTS es perfectamente válida.

El problema es que eso describe a pocos equipos, y que el ecosistema no siempre llega a tiempo: frameworks, agentes de observabilidad y herramientas de análisis de bytecode suelen necesitar su propia actualización antes de soportar una versión nueva. La LTS te compra tranquilidad, no calidad.

Soporte gratuito: lo que cambia entre Temurin y Oracle JDK

Aquí es donde la tabla deja de ser informativa y pasa a tener consecuencias legales. Hay tres cosas distintas que se confunden con «soporte»:

1. Actualizaciones gratuitas: parches que puedes usar en producción sin pagar.
2. Actualizaciones con licencia restringida: existen, pero solo son gratis para desarrollo y uso personal.
3. Soporte de pago: un contrato, con parches y alguien a quien llamar.

Eclipse Temurin: gratis, sin letra pequeña de licencia

Temurin es la distribución de OpenJDK del proyecto Adoptium, de la Fundación Eclipse. Es gratuita también en producción y no tiene una fecha a partir de la cual cambie la licencia. Lo que tiene son fechas de fin de disponibilidad: el momento mínimo hasta el que seguirá publicando versiones.

Eso sí, «soporte» aquí significa comunidad: puedes abrir una incidencia, pero no hay acuerdo de nivel de servicio. Si tu organización lo necesita, tendrás que contratarlo con alguna de las empresas que lo ofrecen sobre Temurin.

Oracle JDK: gratis durante una ventana

Oracle JDK funciona con dos licencias, y el paso de una a otra es lo que hay que vigilar:

• NFTC (No-Fee Terms and Conditions): gratuita para todos, también en producción y con fines comerciales.
• OTN (Oracle Technology Network): gratuita solo para uso personal, desarrollo, pruebas y usos similares. En producción, de pago.

La regla es que cada LTS se publica bajo NFTC hasta un año después de la siguiente LTS, y desde ahí sus parches pasan a OTN. Según las FAQ de licencias de Oracle:

Oracle JDK	Gratuito en producción	Desde aquí, licencia OTN
Java 25	hasta septiembre 2028	lo que se publique después
Java 21	hasta 21.0.12	21.0.13 y siguientes
Java 17	hasta 17.0.12	17.0.13 y siguientes
Java 11	nunca	todas las versiones
Java 8	hasta antes de 8u211	8u211 (abril 2019) y siguientes

La trampa de Oracle JDK 21 desde octubre de 2026

Esto es lo que hay que revisar ahora mismo. La licencia no cambia de golpe para lo que ya tienes instalado; cambia con el siguiente parche. Oracle JDK 21.0.12 sigue bajo NFTC, pero las versiones publicadas desde el 20 de octubre de 2026 van bajo OTN.

Eso deja dos situaciones malas. Si actualizas a 21.0.13 de forma automática, en una imagen base o una tubería de despliegue, pasas a usar en producción un software que requiere licencia de pago, sin que nadie lo haya decidido. Si no actualizas, te quedas sin parches de seguridad.

La salida es sencilla, y no pasa por pagar. Tienes dos opciones:

• Cambiar a Temurin 21: basado en OpenJDK, sin cambiar de versión de Java. En muchos proyectos se reduce a tocar la imagen base.
• Subir a Java 25, que Oracle mantiene gratuita hasta septiembre de 2028 o, mejor, directamente con Temurin.

Lo que no conviene es no decidir. Y esto no es asesoramiento legal: si tienes dudas sobre tu licencia concreta, que las mire quien lleve los contratos.

El soporte de pago de Oracle

Para completar el cuadro, estas son las fechas del calendario de soporte de Oracle. Solo te afectan si tienes contrato; son las que suelen citarse como «fin de soporte» de Java, y por eso generan tanta confusión. Oracle las da como mínimas a partir de Java 17.

Versión LTS	Premier Support hasta	Extended Support hasta
Java 8	marzo 2022	diciembre 2030
Java 11	septiembre 2023	enero 2032
Java 17	septiembre 2026	septiembre 2029
Java 21	septiembre 2028	septiembre 2031
Java 25	septiembre 2030	septiembre 2033
Java 29 (previsto)	septiembre 2032	septiembre 2035

Fíjate en el contraste: Oracle JDK 21 tiene soporte Premier hasta 2028, pero ya no es gratis. Quien lee solo esta tabla concluye que puede estar tranquilo hasta 2028, y es justo la conclusión equivocada.

Qué versión de Java exige cada Spring Boot

En un backend Java, la versión del JDK casi nunca se elige sola: la acota el framework. Estos son los rangos que declara la documentación oficial del último parche de cada línea:

Spring Boot	Java mínimo	Java máximo compatible
4.2 (en desarrollo)	Java 17	Java 27
4.1.2	Java 17	Java 27
4.0.9	Java 17	Java 27
3.5.16	Java 17	Java 25
3.4.13	Java 17	Java 24
3.3.13	Java 17	Java 23
3.2.12	Java 17	Java 23
3.1.12	Java 17	Java 21
3.0.13	Java 17	Java 21
2.7.18	Java 8	Java 21

Tres consecuencias prácticas:

• Spring Boot 4 no te obliga a Java 25. El mínimo sigue siendo Java 17, así que el framework y el JDK se pueden migrar por separado. Es lo más sensato: un cambio cada vez.
• Java 8 y Java 11 te atan a Spring Boot 2.7, sin soporte gratuito desde junio de 2023. Si sigues ahí, el problema no es solo el JDK.
• El máximo se refiere al último parche. Un Spring Boot 3.5 antiguo no tiene por qué declarar lo mismo que el 3.5.16, y el máximo se actualiza con el tiempo: 4.0 y 4.1 ya llegan a Java 27.

Las fechas de soporte de cada línea están en la tabla de versiones de Spring Boot. Si trabajas con esta pila a diario, tienes más en mi libro Spring Boot Avanzado.

Qué versión de Java elegir según tu caso

Sin rodeos, esto es lo que recomendaría en cada situación:

• Proyecto nuevo: Java 25 con Temurin y Spring Boot 4.1. No hay motivo para empezar en una LTS anterior.
• En Java 21 con Temurin: no hay urgencia. Tienes hasta diciembre de 2029. Planifica el salto a 25 sin prisa, cuando te aporte algo.
• En Java 21 con Oracle JDK sin contrato: urgente, por lo explicado arriba. Pasa a Temurin ya y decide después si subes de versión.
• En Java 17: planifícalo este año. Temurin llega al menos a octubre de 2027, y lo natural es saltar directamente a 25, sin pasar por 21.
• En Java 11: hay dos migraciones encadenadas, la del JDK y la de Spring Boot 2.7. Empieza por inventariar dependencias, porque el margen en Temurin es el mismo que en Java 17.
• En Java 8: tienes parches hasta diciembre de 2030, pero el ecosistema se ha ido. El riesgo ya no es el JDK, sino las librerías que han dejado de publicar versiones compatibles.
• Quieres probar lo último: Java 27, en local o en un servicio sin criticidad. Si lo llevas a producción, asume el ciclo de seis meses.

¿Merece la pena esperar a Java 29? No. Falta casi un año, y luego habrá que esperar a que el ecosistema lo adopte. Mientras tanto, Java 25 tiene recorrido de sobra: gratuita en Oracle JDK hasta un año después de que salga la 29, y en Temurin hasta 2031.

Para instalarla, tienes los comandos de macOS, Windows y SDKMAN en la guía de Java 25, y si despliegas en contenedores, la imagen eclipse-temurin y cómo usarla en este Dockerfile para Spring Boot.

Cómo saber qué versión de Java tienes

La parte que más veces se pasa por alto: no basta con saber el número, hay que saber de quién es el JDK, porque de eso depende la licencia.

$ java -version
openjdk version "21.0.12.1" 2026-08-18 LTS
OpenJDK Runtime Environment Temurin-21.0.12.1+1 (build 21.0.12.1+1-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.12.1+1 (build 21.0.12.1+1-LTS, mixed mode, sharing)

La segunda línea dice quién lo compiló: Temurin, Corretto, o Java(TM) SE Runtime Environment en el caso de Oracle JDK. Si quieres el dato limpio para un script:

$ java -XshowSettings:properties -version 2>&1 | grep -E 'java.vendor |java.runtime.version'
    java.runtime.version = 21.0.12.1+1-LTS
    java.vendor = Eclipse Adoptium

Hazlo en el sitio donde corre la aplicación, no en tu portátil. El JDK de tu máquina, el del servidor de integración y el de la imagen de producción no tienen por qué coincidir, y es la primera causa del error que viene a continuación.

El error class file version y qué versión de Java significa

Este error lo ha visto todo el mundo. Lo he reproducido compilando con Java 25 y ejecutando con Java 21:

java.lang.UnsupportedClassVersionError: Hola has been compiled by a more recent
version of the Java Runtime (class file version 69.0), this version of the Java
Runtime only recognizes class file versions up to 65.0

Se lee con una regla sencilla: la versión del fichero .class es la versión de Java más 44. El mensaje dice que la clase es de Java 25 (69) y que quien la ejecuta llega hasta Java 21 (65).

Versión de Java	Java 8	Java 11	Java 17	Java 21	Java 25
Class file version	52	55	61	65	69

La solución no es tocar el código. O ejecutas con un Java igual o más reciente, o compilas para una versión anterior:

javac --release 17 -d out Hola.java

Compilado así con el JDK 25, el .class sale con versión 61 y se ejecuta sin problemas en Java 17. En Maven es la propiedad maven.compiler.release, y en Spring Boot, java.version en el pom.xml. Usa siempre --release y no -source y -target, porque comprueba también que no uses APIs posteriores a esa versión.

Tiene un límite, y da una pista de hacia dónde va todo. Con el JDK 25, --release 8 todavía funciona, pero avisa:

warning: [options] source value 8 is obsolete and will be removed in a future release

Y --release 7 ya falla con error: release version 7 not supported. Compilar para Java 8 con un JDK moderno tiene fecha de caducidad.

Qué viene: Java 28 y Java 29

El calendario próximo está bastante claro:

• Java 28: disponibilidad general el 9 de marzo de 2027 según el calendario de OpenJDK. No será LTS. A 5 de noviembre lista ya funcionalidades como Value Objects en preview, Structured Concurrency ya definitiva y una API de JSON sencilla en incubadora, pero la lista puede cambiar hasta el inicio de la fase de estabilización, el 3 de diciembre.
• Java 29: la siguiente LTS, prevista para septiembre de 2027. Oracle planea mantenerla bajo NFTC hasta septiembre de 2030.
• Java 33: la LTS siguiente según los planes de Oracle, en septiembre de 2029.

Oracle marca estas designaciones como sujetas a cambios, así que tómalas como planificación razonable, no como un compromiso.