📦 Novedades de versiones
La versión estable disponible de forma general (General Availability) más reciente es OpenJDK JDK 27.0.1.0.3 GA Release Builds, publicada el 24 de octubre de 2026. La cadena completa de versión corresponde a 27.0.1.0.3+1.
De acuerdo con las notas de la versión, esta actualización se enfoca principalmente en el mantenimiento de certificados raíz y husos horarios:
- Incorpora los datos de husos horarios IANA 2026e, sincronizando los cambios internacionales de horario de verano (DST).
- Conforme a las directrices de seguridad (JDK-8395690), se eliminan los certificados raíz AAA caducados y no fiables de eMudhra y Comodo (Sectigo) del almacén de confianza integrado
cacerts. - El aviso oficial de línea base de seguridad confirma que el ciclo de soporte de esta versión se extiende hasta la próxima actualización crítica (CPU) programada para el 17 de noviembre de 2026.
La rama de desarrollo JDK 28 sigue en fase de acceso anticipado (Early Access), habiendo publicado la Build 21 el pasado 22 de octubre con dos mejoras destacadas en el sistema de compilación y red:
- Eliminación de la propiedad de sistema
jdk.net.useFastTcpLoopback(JDK-8394531). Tras la depreciación formal por parte de Microsoft del código de controlSIO_LOOPBACK_FAST_PATHen Windows, la JVM eliminó esa ruta redundante. - Inclusión del complemento
jlink --security-properties props(JDK-8377819). Permite sobrescribir o añadir propiedades dejava.securityal construir imágenes de ejecución a medida, simplificando la creación de contenedores ligeros y seguros.
| Plataforma / Versión | Fecha de lanzamiento | Cambios y mecanismos principales | Impacto en producción |
|---|---|---|---|
| OpenJDK JDK 27.0.1.0.3 | 2026-10-24 | Husos horarios IANA 2026e; retirada de certificados raíz caducados de eMudhra/Comodo AAA (JDK-8395690) | Evita riesgos de certificados fraudulentos por CAs caducadas y mantiene la exactitud temporal en pasarelas de pago y tareas programadas. |
| JDK 28 Early-Access (Build 21) | 2026-10-22 | Retirada del atajo TCP loopback en Windows; introducción del plugin jlink --security-properties | Posibilita inyectar políticas de seguridad directamente en imágenes mínimas sin recurrir a montajes de texto plano en el contenedor. |
| Java SE 27 (GA Baseline) | 2026-09-15 | Activos por defecto: JEP 534 Compact Object Headers, JEP 523 G1 universal, JEP 527 TLS 1.3 híbrido poscuántico | Reduce la huella del heap entre un 15 % y un 20 %; elimina la degradación forzada a Serial GC en contenedores con memoria acotada. |
Para profundizar en la arquitectura de cabeceras de objeto compactas de JDK 27, el ajuste fino de G1 y las pruebas de rendimiento, consulte nuestro informe: JDK 27 a fondo.
📝 Artículos en profundidad
1. JDK 28 integra grupos de memoria Confined (PR #31365): latencia de asignación fuera del heap de 6 a 18 veces menor
- Qué ha ocurrido: El 23 de octubre, Per Minborg, miembro clave de OpenJDK Panama, dio a conocer la integración de grupos de memoria nativos para Confined Arenas en JDK 28 (PR #31365). Los análisis revelan que más del 99,99 % de los ámbitos confinados de corta duración (
Arena.ofConfined()) asignan 64 bytes o menos, habitualmente para valores de retorno de llamadas al sistema,errnoo punteros temporales. JDK 28 administra de manera diferida hasta 4 grupos locales de 64 bytes por hilo de plataforma, activándolos ante la primera petición coincidente. - Por qué es relevante: Elimina la sobrecarga de comunicarse con el asignador del sistema operativo y registrar acciones de limpieza segura para fragmentos pequeños fuera del heap. En pruebas sobre Apple M4, la latencia de asignación para 5 bytes pasó de 15,86 ns a 1,05 ns (18,6 veces más rápido); para 20 bytes bajó de 18,14 ns a 1,14 ns (16,8 veces más rápido). En Linux x64 las mejoras alcanzaron entre 6,8 y 7,8 veces, reduciendo también la latencia en hilos virtuales a 3,22 ns.
- A quién afecta: Desarrolladores de middleware, almacenamiento y redes que sustituyen JNI mediante la API Foreign Function & Memory (FFM) de Project Panama para invocar
ioctly llamadas POSIX directamente en el sistema operativo.
2. TornadoVM 7.3: migración integral a Panama FFM y aceleración heterogénea con cuTile y cuBLAS
- Qué ha ocurrido: El 21 de octubre, el framework de código abierto para computación heterogénea en Java TornadoVM presentó su versión 7.3. Esta entrega elimina definitivamente las capas de enlace JNI para apoyarse de lleno en la API estándar FFM en la comunicación con hardware. Además, descarta el interfaz experimental JVMCI y adopta un modelo basado en «reflexión + ASM + Unsafe» para extraer metadatos de compilación, asegurando compatibilidad con JDK 21, 25, 26 y 27.
- Por qué es relevante: Supera las barreras históricas de integración entre Java y las unidades GPU modernas. TornadoVM 7.3 estrena la abstracción
TileContextpara arquitecturas NVIDIA, admitiendo el paradigma de programación por teselas de cuTile. En losTaskGraphspermite combinar llamadas a librerías de álgebra lineal como cuBLAS o CUTLASS con núcleos JIT en ejecuciones encadenadas. También amplía el soporte híbrido para Apple Metal/MLX y la orquestación multi-GPU. - A quién afecta: Equipos que desarrollan arquitecturas unificadas entre la JVM y aceleradores de hardware para inferencia local de modelos de lenguaje, visión por computador y análisis de riesgo financiero de alto rendimiento.
3. La compilación de código máquina AOT de Project Leyden (JEP 544) queda fijada para JDK 28
- Qué ha ocurrido: El 25 de octubre, OpenJDK confirmó formalmente que el JEP 544 (Ahead-of-Time Code Compilation) tiene como versión objetivo oficial JDK 28. Este JEP amplía la caché de clases compartidas (AOT Cache), permitiendo que durante una fase de entrenamiento previa (
java -XX:AOTCacheOutput=app.aot) los compiladores C1 y C2 generen código máquina optimizado que en producción (java -XX:AOTCache=app.aot) se mapea en memoria y ejecuta al instante. - Por qué es relevante: Corrige el consumo excesivo de CPU durante el arranque en frío y el escalado de microservicios. En pruebas bajo Linux x64 de dos núcleos, el uso del código máquina precompilado redujo el tiempo de inicio de los microservicios entre un 65 % y un 80 %, recortando además un 75 % el tiempo de la primera prueba con
javac. Si los patrones de carga en producción invalidan las asunciones previas, la JVM degrada de manera controlada al intérprete y dispara la recompilación dinámica de C2. - A quién afecta: Equipos de ingeniería con microservicios sobre Kubernetes, Knative o plataformas Serverless, así como desarrolladores de sistemas transaccionales sensibles a la fluctuación de latencia del JIT.
4. Project Babylon presenta HAT: generación directa de núcleos CUDA mediante Code Reflection
- Qué ha ocurrido: El 20 de octubre en Devoxx Belgium, el equipo de compiladores de Oracle mostró HAT (Heterogeneous Accelerator Toolkit), un subproyecto englobado en Project Babylon. Apoyándose en la futura API Code Reflection, HAT extrae código de cómputo en Java durante la ejecución como modelos inspeccionables y los compila automáticamente a núcleos OpenCL o CUDA.
- Por qué es relevante: Supera la limitación por la que Java no podía inspeccionar el flujo de control interno de los métodos como metadatos. Los desarrolladores pueden codificar operaciones tensoriales con bucles tradicionales de Java sin escribir código C o CUDA por separado; HAT se encarga de adaptarlo a la disposición de memoria de los núcleos tensoriales de la GPU. Las pruebas en vivo con NVIDIA Nsight Compute evidenciaron la madurez de la herramienta para entornos industriales.
- A quién afecta: Creadores de motores de cálculo tensorial e ingenieros de computación científica de alto rendimiento en busca de abstracciones de hardware unificadas.
🔥 Debates en la comunidad
1. r/java prohíbe de forma tajante el código asistido por IA: la regla número 9 desata la polémica sobre gobernanza
- Métricas: Artículo de análisis del veterano programador de Java Steve Hannah; el hilo en Hacker News sumó 28 puntos y 86 comentarios (50167524).
- Contexto: El autor de la herramienta jDeploy, Steve Hannah, compartió en el subreddit r/java un componente Swing WebView que había desarrollado, tras lo cual recibió una expulsión permanente (Lifetime Ban) inmediata en aplicación de la regla 9 (Rule #9: prohibición estricta de compartir software o contenidos creados con asistencia de IA).
- Puntos en conflicto:
- Defensores del filtro antispam y la calidad: Los moderadores y miembros afines argumentan que la popularidad de las herramientas generativas ha provocado una oleada de librerías mediocres sin testear. Al no disponer los voluntarios del tiempo necesario para auditar cada línea, consideran que una política de tolerancia cero es imprescindible para mantener el nivel técnico del foro.
- Partidarios de la evaluación pragmática por resultados: Los desarrolladores opuestos señalan que un proyecto de código abierto debe juzgarse por su cobertura de pruebas, diseño de interfaces y solidez en ejecución, y no por quién pulsó las teclas. Incluso Linus Torvalds reconoció recientemente haber empleado IA para programar utilidades en Java; los críticos advierten que una pesquisa sobre el origen del código solo consigue apartar a colaboradores veteranos.
2. La versión en Java de Campfire supera a Rust: la optimización dinámica JIT frente al AOT estático
- Métricas: Hilo de análisis de rendimiento en Reddit r/java, compartido en Hacker News por Bruno Borges, Principal Java PM en Microsoft (50152924).
- Contexto: A raíz de los experimentos de 37signals para trasladar el servicio Campfire a lenguajes de sistemas, varios ingenieros crearon una reimplementación en Java con Quarkus. Al evaluar el servicio en JDK 28 con la caché AOT de JEP 544 bajo concurrencia extrema, la versión en Java arrojó un rendimiento y unas latencias p99 superiores a la rama experimental en Rust en supuestos específicos.
- Puntos en conflicto:
- Defensores del entorno de ejecución moderno: La compilación escalonada de HotSpot, la optimización guiada por perfiles y la desvirtualización inline cuentan con tres décadas de perfeccionamiento. En cargas web prolongadas, el análisis dinámico supera a menudo a los compiladores estáticos. Con JEP 544 resolviendo el arranque en frío, Java demuestra que puede competir en concurrencia con lenguajes de sistemas garantizando seguridad en memoria.
- Especialistas en sistemas y escépticos del benchmark: La comunidad de Rust cuestionó el rigor de las pruebas, remarcando que la versión en Rust era una traducción casi literal repleta de copias de memoria innecesarias. Además, recalcan que aunque el rendimiento en bruto sea similar, la memoria residente (RSS) de HotSpot y la sobrecarga de las barreras de recolección de basura suponen un consumo de ancho de banda muy distinto al de un lenguaje sin GC.
🔭 Próximos hitos de interés
- Preparativos para el ciclo de parches de noviembre de 2026: Según la planificación de seguridad de Oracle, la siguiente actualización crítica (CPU) se publicará el 17 de noviembre de 2026. Se aconseja a los administradores de sistemas comprobar la repercusión de los cambios en los certificados de JDK 27.0.1.0.3 en redes PKI internas y sistemas de pago.
- Llegada de JDK 28 Build 22: La próxima integración de código está prevista para el jueves 29 de octubre. La atención se centrará en el progreso de las pruebas de regresión de JEP 535 (modo generacional activado por defecto en Shenandoah GC).
