JDK 27 alcanza disponibilidad general con G1 GC por defecto en todas las plataformas

Recientemente, OpenJDK 27 alcanzó su disponibilidad general, convirtiéndose en la implementación de referencia de la versión 27 de la plataforma Java SE según la JSR 402. Los binarios listos para producción bajo licencia GPL ya están disponibles a través de Oracle, y los de otros proveedores les siguen poco después.

Esta es una versión no LTS, con soporte de Oracle previsto hasta marzo de 2027, lo que la sitúa como una actualización de innovación para quienes desean adoptar mejoras de rendimiento y seguridad antes del próximo ciclo de soporte a largo plazo.

Más de 2.300 commits y dos cambios que lo cambian todo

La nota de rendimiento publicada por el equipo de Java es contundente: más de 2.300 commits han aterrizado en OpenJDK desde JDK 26, con cambios que afectan a las librerías, los recolectores de basura, el compilador JIT y el runtime. Pero por encima de todos, destacan dos modificaciones con un alcance transversal:

1. Compact Object Headers habilitado por defecto (JEP 534)

Esta es, probablemente, la mejora de mayor impacto práctico en JDK 27. Los Compact Object Headers reducen el tamaño de la cabecera de los objetos en la JVM HotSpot de 96 bits a 64 bits en arquitecturas de 64 bits. El resultado directo es una reducción del heap de aproximadamente un 20%, con beneficios en cascada: menor presión sobre el recolector de basura, mejor densidad de despliegue y mejor localidad de datos.

La característica se introdujo como funcionalidad final en JDK 25, pero requería activarla manualmente con -XX:+UseCompactObjectHeaders. En JDK 27, ya no es necesario hacer nada: está activada por defecto. Si por alguna razón necesitas desactivarla, puedes hacerlo con -XX:-UseCompactObjectHeaders.

Impacto práctico: Aplicaciones que gestionan grandes volúmenes de objetos pequeños —como servicios de microservicios, procesamiento de eventos o cargas de trabajo con muchos objetos de vida corta— verán una reducción inmediata del consumo de memoria sin cambiar una línea de código.

2. G1 como recolector de basura por defecto en todos los entornos (JEP 523)

G1 (Garbage-First) era el recolector por defecto desde JDK 9, pero solo en entornos de servidor. En escenarios con recursos limitados —contenedores pequeños, máquinas con poca CPU o heaps reducidos—, la JVM seleccionaba automáticamente Serial GC. JDK 27 elimina esa excepción: G1 será el recolector por defecto en todos los casos, a menos que se especifique explícitamente otro.

El equipo de Java justifica la decisión señalando que G1 ha mejorado de forma continuada en versiones posteriores, hasta el punto de que incluso en entornos con recursos limitados suele ser la mejor opción. La documentación de Oracle añade que, en los escenarios donde antes se seleccionaba Serial GC, las métricas de rendimiento —throughput, latencia, huella de memoria y tiempo de arranque— no deberían degradarse significativamente.

Nota importante: Como recuerda la propia documentación, no existe un “mejor recolector universal”. Cada GC hace concesiones entre uso de CPU, uso de memoria, pausas y otros KPIs. Si tu aplicación tiene necesidades específicas, mide y elige conscientemente en lugar de asumir el valor por defecto.

La criptografía post-cuántica llega a TLS 1.3

Uno de los focos más relevantes de JDK 27 es la seguridad. Y no se trata solo de nuevas APIs, sino de funciones que hacen que las aplicaciones existentes sean más seguras simplemente actualizando la versión del JDK.

JEP 527: Intercambio de claves híbrido post-cuántico para TLS 1.3

Java 27 introduce métodos de intercambio de claves híbridos que combinan algoritmos clásicos (ECDHE) con algoritmos resistentes a la computación cuántica (ML-KEM). El problema que aborda es concreto: aunque los computadores cuánticos capaces de romper la criptografía actual aún no existen, los atacantes ya pueden grabar tráfico cifrado y esperar a descifrarlo en el futuro —el escenario conocido como “harvest now, decrypt later”.

Java 27 soporta tres grupos híbridos nombrados:

La gran ventaja para los desarrolladores es que el cambio es transparente. Las aplicaciones que usan javax.net.ssl, HTTPS o HttpClient no necesitan modificar su código: X25519MLKEM768 figura entre los grupos TLS 1.3 preferidos de Java 27, y si el servidor también lo soporta, la negociación ocurre durante el handshake normal.

JEP 536: Redacción de datos sensibles en JFR

Java Flight Recorder (JFR) ahora redacta por defecto información sensible como contraseñas, claves de API y tokens que se pasen como argumentos de la JVM, variables de entorno o propiedades del sistema. Los filtros por defecto cubren patrones comunes como *password*, *secret*, *token*, *private*key* y muchos otros.

Además, puedes añadir tus propios filtros con patrones glob (sensible a mayúsculas) o desactivar los predeterminados por completo con redact-key=none. Para entornos regulados o con requisitos estrictos de privacidad, esta funcionalidad elimina una fuente habitual de fugas accidentales de secretos en perfiles de diagnóstico.

Librerías: mejoras de rendimiento medibles

JDK 27 incluye varias optimizaciones en librerías que, aunque menos visibles, producen mejoras medibles en escenarios concretos:

• HashMap.putAll() y el constructor HashMap(Map): se han añadido rutas especializadas que evitan la maquinaria de iteradores y el recálculo de hashes. En AWS Graviton, con call sites expuestos a cinco tipos de Map, las reducciones de tiempo de operación fueron de 61% para un HashMap de cinco entradas y 86% para un Map inmutable de 150 entradas (de ~10.593 ns/op a 1.533 ns/op).
• Procesamiento de texto con atributos: AttributedString ha reemplazado su estructura de arrays de Vector por un array de mapas, eliminando búsquedas lineales. En el benchmark presentado, la iteración con uno o más atributos tardó entre un 35% y un 40% menos, y la creación de una cadena con un atributo asignó alrededor de un 20% menos de memoria.
• Formateo de URL: URL.toString() se ha optimizado, un cambio que afecta a perfiles de arranque y carga de clases.

APIs en preview e incubación: lo que viene

JDK 27 incluye cuatro características en preview y una en incubación, que aunque no deben usarse en producción sin --enable-preview, marcan la dirección futura de la plataforma:

Lazy Constants (JEP 531) es especialmente relevante para aplicaciones de IA y datos: permite definir objetos que se calculan en el primer acceso y solo una vez, y que la JVM trata como constantes verdaderas para optimizaciones como el plegado de constantes, sin necesidad de inicialización anticipada ni sincronización manual.

Vector API (JEP 537) continúa en incubación tras doce iteraciones, ofreciendo un mecanismo para expresar computaciones vectoriales que se compilan en tiempo de ejecución a instrucciones vectoriales óptimas en CPUs compatibles.

Consideraciones para la adopción

Es una versión no LTS

JDK 27 no es una versión de soporte a largo plazo (LTS). Oracle proporcionará actualizaciones hasta marzo de 2027. Si necesitas estabilidad a largo plazo, las LTS actuales son JDK 21 (soporte hasta 2031) y JDK 25 (soporte hasta 2033). JDK 27 está pensado para equipos que quieren adoptar mejoras de rendimiento y seguridad de forma temprana y están dispuestos a actualizar de nuevo en pocos meses.

La migración desde JDK 26 es directa, pero verifica

Los cambios de mayor impacto —Compact Object Headers y G1 por defecto— están activados automáticamente y están diseñados para no requerir cambios de código. Sin embargo, cualquier cambio en el comportamiento por defecto del recolector de basura o en la disposición de memoria merece una validación en tu entorno específico. Los propios ingenieros de Java insisten en la necesidad de medir y probar antes de asumir que los nuevos valores por defecto son óptimos para cada carga de trabajo.

Dependencias del ecosistema

Antes de actualizar, verifica que tus frameworks, bibliotecas y herramientas de build soportan JDK 27. Al ser una versión no LTS recién publicada, es posible que algunos proyectos del ecosistema tarden unas semanas en declarar compatibilidad oficial.