Antes de Java 9, cada versión nueva de Java tardaba entre dos y tres años en llegar. Java 8 salió en marzo de 2014 y su sucesor, Java 9, no apareció hasta septiembre de 2017. Tres años y medio acumulando trabajo, postergando decisiones y aguantando limitaciones del lenguaje que todos conocían pero nadie podía tocar.
En 2017 Oracle cambió el modelo: una versión nueva cada seis meses, en marzo y en septiembre. La idea es que cada mejora sale cuando está lista, no cuando coincide con el release que tenga más peso político interno. El resultado es que tienes versiones más pequeñas, más predecibles y con menos sorpresas.
El otro cambio importante fue el ciclo LTS (Long-Term Support). Las versiones con soporte extendido son Java 8, 11, 17, 21 y la próxima Java 25. Las versiones entre medias (22, 23, 24) tienen soporte solo hasta que sale la siguiente release, unos seis meses. Para producción, la regla es sencilla: usa siempre una LTS.
Java 21 LTS: lo que más importa
Java 21 salió en septiembre de 2023 y es la LTS vigente. Trae varios cambios importantes, pero hay uno que merece mención aparte: los virtual threads.
Virtual threads (Project Loom)
Los virtual threads son el cambio de concurrencia más relevante en Java en los últimos veinte años. El problema clásico de Java con I/O intensivo es que un thread del sistema operativo es caro: ocupa memoria, cuesta crear y destruir, y bloquear uno mientras espera una respuesta de base de datos o red es un despilfarro. La solución habitual era usar programación reactiva o callbacks, que funcionan pero complican el código.
Con los virtual threads puedes escribir código bloqueante normal y la JVM se encarga de multiplexar las operaciones de I/O sobre un número pequeño de threads del sistema. El código queda tan sencillo como con threads tradicionales pero con la eficiencia de un modelo asíncrono.
// Virtual thread en Java 21
Thread.ofVirtual().start(() -> {
// Aquí puedes hacer llamadas bloqueantes sin problema
String resultado = httpClient.get("https://api.ejemplo.com/datos");
procesar(resultado);
});
Pattern matching for switch y record patterns
El pattern matching for switch llega a GA en Java 21. Ya no necesitas hacer cast manual después de un instanceof:
// Java 21: pattern matching en switch
switch (obj) {
case Integer i when i > 0 -> System.out.println("Positivo: " + i);
case Integer i -> System.out.println("No positivo: " + i);
case String s -> System.out.println("Texto: " + s);
default -> System.out.println("Otro tipo");
}
Los record patterns permiten desestructurar directamente en el pattern:
record Point(int x, int y) {}
if (obj instanceof Point(int x, int y)) {
System.out.println("Coordenadas: " + x + ", " + y);
}
Sequenced collections
Java 21 introduce SequencedCollection, SequencedSet y SequencedMap, que añaden una API consistente para acceder al primer y al último elemento de cualquier colección ordenada. Antes cada tipo tenía su propio método o requería un iterador. Ahora hay getFirst(), getLast(), reversed() en todas las colecciones que tienen orden definido.
String templates: el experimento que no salió bien
Los string templates llegaron en Java 21 como preview. El objetivo era tener interpolación de variables en strings con validación en tiempo de compilación. En Java 23 los eliminaron porque el enfoque no convenció: demasiado complejo para lo que aportaba. Si en algún momento los ves en documentación antigua, ten en cuenta que ya no existen en las versiones actuales.
Java 22 y 23: features de transición
Las versiones entre LTS sirven para probar features antes de estabilizarlas. Las más útiles de este ciclo:
Unnamed variables y unnamed patterns
El guion bajo (_) ahora tiene uso oficial en Java. Puedes usarlo para indicar que una variable existe pero no te importa su valor:
// Capturar excepción sin usar la variable
try {
// ...
} catch (IOException _) {
return defaultValue;
}
// Ignorar parte de un record pattern
case Point(int x, _) -> System.out.println("Solo x: " + x);
Markdown en Javadoc
Desde Java 23 puedes escribir comentarios de documentación en Markdown en lugar de HTML. Los bloques que empiecen por /// se interpretan como Markdown:
/// Calcula el área de un círculo.
///
/// @param radio el radio en metros
/// @return el área en metros cuadrados
public double calcularArea(double radio) {
return Math.PI * radio * radio;
}
Stream Gatherers
Los stream gatherers permiten crear operaciones intermedias personalizadas para streams, algo que antes requería soluciones creativas o librerías externas. Llegaron como preview en Java 22 y se estabilizaron en Java 24.
Java 24: AOT y el rendimiento al arranque
Java 24 salió en marzo de 2025 y su feature más destacada es el JEP 483: AOT class loading and linking.
La idea es simple: la primera vez que arrancas tu aplicación, la JVM carga y enlaza todas las clases. Esa operación cuesta tiempo. Con el AOT cache, ese trabajo se guarda en disco y las siguientes veces se recupera directamente:
# Crear la caché AOT
java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -jar app.jar
# Usar la caché en arranques posteriores
java -XX:AOTMode=on -XX:AOTConfiguration=app.aotconf -jar app.jar
Esto no es lo mismo que GraalVM native image, que compila la aplicación a un binario nativo sin JVM. El AOT cache de Java 24 sigue usando la JVM normal, pero ahorra el trabajo de carga de clases en cada arranque. Para aplicaciones con muchas clases o microservicios que escalan rápido, el impacto puede ser notable.
Java 24 también estabiliza la Class File API (JEP 484), que permite manipular bytecode Java directamente desde el JDK sin depender de librerías como ASM o Javassist. Útil principalmente para herramientas de build, profilers y frameworks que generan código en tiempo de ejecución.
Java 25 LTS: el próximo destino
Java 25 sale en septiembre de 2025 y será la siguiente LTS. Acumula todo lo que ha madurado en el ciclo 21-24. Las features que llevan varias versiones en preview y son candidatas a llegar a GA en Java 25 son los stream gatherers, las unnamed classes (clases sin declaración explícita, útiles para scripts pequeños) y los primitive types in patterns.
Para proyectos que todavía están en Java 17 y no han dado el salto a 21, Java 25 es el destino natural si quieren esperar a la próxima LTS. El salto de 17 a 25 recoge cuatro años de mejoras del lenguaje de una vez.
Qué versión usar en 2026
La respuesta depende de dónde estés ahora:
- Producción nueva: Java 21 LTS. Es la más estable, tiene el mayor soporte comercial disponible y los frameworks principales ya la soportan con todas sus features.
- Nuevos proyectos desde cero: Java 21 hasta que Java 25 esté bien consolidado. Para finales de 2025 o principios de 2026 Java 25 será la opción obvia.
- Proyectos en Java 17: La migración a 21 merece la pena sobre todo por los virtual threads. Si tu aplicación hace I/O intensivo, el cambio puede ser muy significativo con poco código modificado.
- Proyectos en Java 11 o anterior: Actualizar es urgente. Java 11 tiene soporte extendido pagando, pero hay dos LTS más modernas disponibles gratis.
- Proyectos en Java 8: El soporte gratuito de Oracle expiró hace años. Si sigues en Java 8 en producción, la deuda técnica es seria.
Las versiones no-LTS (22, 23, 24) tienen sentido solo si desarrollas herramientas, quieres probar features en preview o tu pipeline de CI puede actualizar la JVM cada seis meses sin fricción. Para la mayoría de equipos, no vale la pena.
Distribuciones: cuál descargar
OpenJDK es el código fuente de referencia, pero hay varias distribuciones binarias. Las principales:
- Eclipse Temurin (antes AdoptOpenJDK): la opción gratuita más usada. Builds para todas las plataformas, mantenida por la Eclipse Foundation con respaldo de empresas como IBM, Microsoft y Red Hat.
- Amazon Corretto: gratuito, mantenido por Amazon y optimizado para su infraestructura. Buena opción si despliegas en AWS.
- Azul Zulu: gratuito, con builds para ARM incluyendo Apple Silicon. Útil si desarrollas en Mac con chip M.
- Microsoft Build of OpenJDK: gratuito, orientado a Azure, con soporte de Microsoft.
- Oracle JDK: soporte comercial de pago. Necesario si tienes contrato de soporte con Oracle o usas funciones propietarias de Oracle.
- GraalVM: incluye el compilador JIT avanzado de GraalVM y la posibilidad de compilar a binario nativo. Para casos de uso concretos donde el tiempo de arranque o la huella de memoria son críticos.
Para gestionar varias versiones en local, SDKMAN es la herramienta más cómoda:
# Instalar SDKMAN
curl -s "https://get.sdkman.io" | bash
# Instalar Java 21 de Eclipse Temurin
sdk install java 21.0.3-tem
# Cambiar de versión en el directorio actual
sdk use java 21.0.3-tem
El impacto de Java 21 en los frameworks
Los virtual threads han llegado a los frameworks principales con poco esfuerzo de configuración:
- Spring Boot 3.2+: activar virtual threads es una línea en el fichero de configuración:
spring.threads.virtual.enabled=true. Spring MVC y Spring WebFlux los soportan. - Quarkus 3.x: la anotación
@RunOnVirtualThreadsobre un método REST indica que ese endpoint se ejecuta en un virtual thread. - Tomcat 10.1+: soporte nativo de virtual threads como ejecutores de peticiones HTTP.
- Micronaut 4.x: soporte integrado para virtual threads en endpoints bloqueantes.
La mayoría de aplicaciones que hacen llamadas a base de datos o APIs externas se benefician de los virtual threads sin cambiar el código de negocio. El cambio está en el servidor de aplicaciones o en la configuración del framework.
Si quieres profundizar en los detalles de concurrencia, en concurrencia en Java: de threads a virtual threads en 2026 tienes un análisis más detallado de cómo funciona Project Loom por dentro. Y si te interesa el futuro de la JVM a nivel más bajo, JEP 401 y las clases de valor explica el trabajo que viene después de los virtual threads.
Imagen: Pexels / panumas nikhomkhai