JDK 27 retrasa su release candidate al 20 de agosto, pero mantiene la disponibilidad general en septiembre

Mark Reinhold, arquitecto jefe de Java en Oracle, ha movido la fecha de la primera release candidate de JDK 27 del 6 al 20 de agosto de 2026. El motivo no tiene nada que ver con bugs en el propio JDK: es un ajuste de calendario para que la RC coincida con la próxima ronda de Critical Patch Updates (CPU), prevista para el 18 de agosto.

El cambio recorta la ventana de feedback sobre la RC de cinco semanas y cuatro días a tres semanas y cuatro días. Suena a menos margen, y lo es, pero el propio equipo señala que desde que Java pasó al ciclo de seis meses con JDK 10, menos de la mitad de las releases han necesitado una segunda build de RC, y ninguno de los bugs que la motivaron llegó reportado por usuarios finales. La fecha de disponibilidad general de JDK 27 se mantiene: 15 de septiembre de 2026.

Qué trae JDK 27

Mientras se resuelve el calendario, las nueve features candidatas para esta versión siguen su curso:

• G1 como recolector por defecto en todos los entornos (JEP 523), no solo en entornos de servidor como hasta ahora.
• Intercambio híbrido de claves post-cuántico para TLS 1.3 (JEP 527), combinando algoritmos resistentes a computación cuántica con los tradicionales.
• Constantes perezosas (JEP 531), en tercera vista previa, para objetos con datos inmutables cuya inicialización se puede diferir.
• Tipos primitivos en patrones, instanceof y switch (JEP 532), en quinta vista previa.
• Concurrencia estructurada (JEP 533), en séptima vista previa, con una API que trata grupos de tareas concurrentes como una sola unidad de trabajo.
• Cabeceras de objeto compactas (JEP 534), que reducen el header de cada objeto de 96 a 64 bits en arquitecturas de 64 bits, con el consiguiente ahorro de heap.
• Redacción de datos JFR en proceso (JEP 536), para ocultar argumentos de línea de comandos y variables sensibles en los perfiles de Java Flight Recorder.
• API Vector (JEP 537), ya en su duodécima ronda de incubación.
• Codificaciones PEM para objetos criptográficos (JEP 538), con una API para codificar y decodificar claves, certificados y listas de revocación.

Entre todas, la que más impacto silencioso va a tener es probablemente G1 por defecto en todos los entornos: para muchas aplicaciones que hoy corren con el recolector serial sin haberlo elegido a propósito, el cambio debería notarse en menos pausas y mejor rendimiento sin tocar una línea de configuración.

Más información en ADTmag.

Relacionado: Virtual threads en Java 21 y Java moderno en 2026: records, sealed classes y pattern matching.