Java 27: más velocidad sin tocar tu código

Java 27 llega con fecha de disponibilidad general el 15 de septiembre de 2026 y con un conjunto de novedades más discreto de lo habitual: solo nueve JEPs (JDK Enhancement Proposals, las propuestas formales de cambio en el JDK).

Pero discreto no significa poco interesante. Las mejoras más jugosas de esta versión están en las tripas de la JVM, la máquina virtual de Java, como vamos a ver enseguida.

Al no ser una versión LTS (Long Term Support, la que reciben soporte extendido durante años: la siguiente no es hasta septiembre de 2027), muchas empresas se la saltarán directamente en espera de la siguiente LTS. Pero si administras servidores en producción o simplemente te interesa por dónde va la plataforma, hay motivos de peso para conocerla ya, e incluso actualizar las aplicaciones a esta versión.

Vamos a repasar qué cambia de verdad (características finales, ya activas por defecto) y qué sigue siendo un boceto en preview o incubación, que es donde suele haber más confusión.

G1 es ahora el recolector por defecto en Java 27

Desde el JDK 9, allá por 2017, G1 (Garbage First) es el recolector de basura por defecto... pero solo en máquinas con varios cores y bastante memoria. Si tu JVM detectaba pocos recursos disponibles (menos de 2 cores o menos de 1792 MB de RAM), el JDK se echaba atrás y usaba Serial GC, un recolector pensado para instancias pequeñas o entornos con recursos limitados.

Con el JEP 523, esa distinción desaparece. G1 pasa a ser el recolector por defecto en todos los entornos, sin excepciones por tamaño de máquina. ¿El motivo? Los contenedores pequeños (piensa en microservicios corriendo con 512 MB de RAM en Kubernetes) se han vuelto la norma, no la excepción, y Serial GC empezaba a quedarse corto en escenarios donde antes tenía sentido. El mundo ha cambiado mucho en casi 10 años.

G1 divide el heap en regiones y prioriza recolectar primero las que tienen más basura (de ahí el nombre). Esto se traduce en pausas más cortas y predecibles, algo que Serial GC no hace bien porque "detiene el mundo entero" (stop-the-world se le llama) durante la recolección. Ya te hablamos con más detalle de las mejoras de G1 cuando salió la versión 26 de Java el pasado marzo. Mira algunos detalles interesantes allí.

Si nunca has tocado los flags de GC en tu vida (yo el primero), este cambio no te va a afectar. Si alguna vez forzaste -XX:+UseSerialGC a mano por ir sobre memoria ajustada, ahora ya no hace falta: el JDK toma la decisión correcta por defecto.

Cabeceras de objeto compactas en Java

Cada objeto Java en memoria arrastra un "peaje" antes de sus datos reales: la cabecera de objeto (object header). Hasta ahora ocupaba 96 bits en sistemas de 64 bits, divididos en dos partes: el Mark Word (con el hash de identidad, la edad del objeto para el recolector generacional y los bits de bloqueo para synchronized) y el Class Word (un puntero a los metadatos de la clase):

El problema es que gran parte de esos 96 bits estaban sin usar. Desde Java 24 existía una alternativa experimental para comprimir todo en 64 bits, y en Java 25 pasó a ser una función de producción, aunque había que activarla a mano con -XX:+UseCompactObjectHeaders.

Con el JEP 534, esa cabecera compacta se activa por defecto. Mark Word y Class Word se fusionan en un único valor de 64 bits, aprovechando los bits que antes estaban vacíos para meter ahí un puntero comprimido a la clase:

¿El resultado práctico? El consumo de heap baja entre un 10% y un 20%, y la velocidad de procesado sube entre un 5% y un 10%, especialmente en aplicaciones con muchos objetos pequeños (colecciones, DTOs, structs...).

Por ejemplo, si trabajas con Spring Boot, microservicios o cualquier cosa que instancie miles de objetos por segundo, este cambio te beneficia sin que cambies una sola línea de código.

Puedes desactivarlo con -XX:-UseCompactObjectHeaders si algún día lo necesitas, aunque esa opción tiene fecha de caducidad en versiones futuras.

Los cambios de memoria son invisibles para el día a día. Los de seguridad, en cambio, empiezan a preocupar a cualquiera que lea las noticias sobre computación cuántica.

¿Es la TLS de Java 27 segura frente a ordenadores cuánticos?

Aquí la cosa se pone interesante. El JEP 527 añade a TLS 1.3 (el protocolo que cifra casi todo el tráfico HTTPS de internet) soporte para intercambio de claves híbrido postcuántico.

¿Qué significa "híbrido"? Que la conexión combina un algoritmo clásico (el que usamos hoy, como ECDHE) con uno resistente a ataques de computadores cuánticos. Si el algoritmo cuántico resulta tener un fallo (todavía son relativamente nuevos y menos probados que los clásicos), la seguridad clásica sigue ahí de respaldo. Si el clásico cae ante un futuro ordenador cuántico suficientemente potente, el componente postcuántico es el que aguanta el tipo.

El riesgo que motiva incluir esto en casi todas las plataformas tiene nombre: "harvest now, decrypt later" (cosecha ahora, descifra después). Un atacante puede guardar hoy tráfico cifrado que no puede romper, y esperar a tener un ordenador cuántico capaz de descifrarlo dentro de unos años. Para datos con vida útil larga (historiales médicos, secretos de estado, contraseñas maestras) eso es un problema del futuro que empieza hoy.

Para el desarrollador de a pie esto no exige ningún cambio de código: si usas las APIs estándar de TLS del JDK, te beneficias de la mejora en cuanto ambos extremos de la conexión lo soporten. Es una función que trabaja en segundo plano, protegiéndote de una amenaza que todavía no existe pero que empieza a tomarse en serio.

Y ahora, de amenazas futuras a problemas muy actuales: la siguiente novedad ataca un problema que seguro que ya has sufrido alguna vez sin darte cuenta.

¿Puede JFR filtrar tus contraseñas?

El JDK Flight Recorder (JFR) es la herramienta de profiling y diagnóstico integrada en la JVM. Cuando grabas una sesión de JFR para depurar un problema de rendimiento, captura muchísima información útil, incluyendo variables de entorno, propiedades del sistema y argumentos de arranque de tu aplicación.

El problema salta a la vista si arrancas tu aplicación así:

java -Ddb.password=SuperSecreta123 -jar mi-app.jar

Ese -D con la contraseña en texto plano queda grabado tal cual en el fichero .jfr 🤦🏻‍♂️ Si compartes esa grabación con un compañero, la subes a un ticket de soporte o la analizas en una herramienta externa, la contraseña viaja con ella. Es un vector de fuga de credenciales sorprendentemente común, porque nadie piensa en el perfilador como una fuente de riesgo.

El JEP 536 resuelve esto con censura automática. El JFR detecta patrones habituales de nombres sensibles (password, secret, token, key, entre otros) en variables de entorno, propiedades del sistema y argumentos de programa, y los sustituye por [redacted] antes de que el dato salga del proceso.

No tienes que activar nada especial ni cambiar tu forma de lanzar la aplicación, pues la protección viene de serie.

Estas cuatro son las novedades que ya puedes dar por definitivas. El resto de la lista de JDK 27 todavía se está cocinando, pero puede ser interesante probarlas para cuando sean definitivas.

¿Qué llega como preview en Java 27?

Primero hay que aclarar la diferencia que existe entre características en estado _preview y en estado incubación. Ambos son sinónimos de "todavía no estable", pero Una API en preview puede cambiar (o incluso desaparecer, aunque es más raro) en la siguiente versión, y para usarla necesitas compilar y ejecutar con el flag --enable-preview. Por su lado, el estado de incubación es incluso una fase menos madura reservada para APIs completamente nuevas que ni siquiera tienen paquete definitivo y se están experimentando o evolucionando.

Ninguna de las siguientes novedades de Java 27 es apta para código de producción serio todavía:

• Lazy Constants (JEP 531, tercera preview): una API para constantes de inicialización perezosa. La idea es tener el valor calculado solo la primera vez que se necesita, pero garantizando que a partir de ahí es inmutable de verdad (algo que hoy se resuelve con trucos manuales bastante feos).
• Patrones en tipos primitivos, instanceof y switch (JEP 532, quinta preview): extiende el pattern matching (la técnica para desestructurar y comprobar la forma de un valor en una sola expresión) para que funcione también con tipos primitivos como int o double, no solo con objetos.
• Concurrencia estructurada (JEP 533, séptima preview): trata un grupo de tareas concurrentes relacionadas como una sola unidad, de forma que si una falla, se cancelan las demás automáticamente. Lleva ya siete rondas de preview, lo cual da una idea de lo delicado que es esta característica.
• Codificación PEM para objetos criptográficos (JEP 538, tercera preview): una API estándar para codificar y decodificar claves y certificados en formato PEM (el formato de texto en base64 que ves en los ficheros .pem o .crt de los certificados), sin depender de bibliotecas de terceros para algo tan básico.
• A eso se suma la Vector API (JEP 537), en su décimo segunda ronda de incubación. Permite escribir cálculos vectoriales que el compilador traduce a instrucciones SIMD de la CPU. Útil para cargas de trabajo numéricas intensivas. Doce rondas sin salir de incubación dice mucho de lo difícil que es diseñar bien una API de bajo nivel como esta.

Mi opinión: Structured Concurrency lleva tanto tiempo en preview que empieza a generar cierto hartazgo. Pero es justo el tipo de característica que es preferible que vaya muy despacio mejor que dejar que llegue rota a producción y empiece a dar problemas.

¿Merece la pena actualizar a Java 27?

Depende de qué tengas entre manos. Si gestionas microservicios con memoria ajustada, las cabeceras compactas y el cambio de GC por defecto son motivo suficiente para probarla en un entorno de pruebas. Si tu aplicación toca TLS con datos sensibles a largo plazo, vale la pena entender el soporte postcuántico aunque no lo actives todavía de forma explícita.

Pero si lo que buscas es una versión LTS estable para quedarte varios años, Java 27 no es esa versión. Java 25 (la LTS anterior) sigue siendo la opción más recomendable para producción seria si todavía no has migrado.

Java 27 es más bien un adelanto de lo que probablemente veremos consolidado en la próxima LTS dentro de un año, con la concurrencia estructurada y la desestructuración de tipos primitivos como los grandes candidatos a salir por fin de la fase preview.

Mi recomendación, como siempre con versiones no LTS: pruébala en un entorno controlado, mide el impacto real de las cabeceras compactas en tu caso concreto (los porcentajes que da Oracle son orientativos, no una garantía) y decide con datos propios, no solo con lo que lees en un blog (incluido este 😉).

¡Espero que te resulte útil!