Project Valhalla aterriza en JDK 28: 197.000 líneas de código que cambian Java para siempre

Oracle confirma que JEP 401 —Value Classes and Objects— se integrará en el repositorio principal de OpenJDK como feature en preview. Es el mayor cambio estructural del lenguaje desde los genéricos en 2004. Y llega tras 12 años de trabajo.

El 15 de junio de 2026, el ingeniero de Oracle Lois Foltan confirmó en la lista de correo de OpenJDK lo que media industria ya había dejado de creer: JEP 401 se integra en el mainline. El pull request es tan enorme —197.000 líneas de código en 1.816 archivos— que Foltan pidió al resto de committers que pausaran los commits grandes durante la integración. No es para menos.

El lema del proyecto lo resume todo: "codes like a class, works like an int". La idea es tan simple como brutal: poder escribir clases normales, con métodos, validaciones y nombres de campo legibles, pero que la JVM las trate con la misma eficiencia que un int primitivo. Para entender por qué esto es revolucionario hay que retroceder a los cimientos de Java.

El problema: todo es un puntero

En Java, salvo los 8 tipos primitivos (int, long, double, boolean...), absolutamente todo es un tipo por referencia. Cuando escribes Point p = new Point(1, 2), la variable p no contiene un punto. Contiene un número de ticket de guardarropa: en algún lugar del heap hay un objeto, y tú sostienes un papelito con su dirección. Cada vez que quieres leer un campo, la JVM tiene que seguir ese puntero —pointer indirection— con su correspondiente penalización de caché.

Para un solo objeto no es nada. El problema llega a escala. Cada objeto en el heap tiene su header —una docena de bytes de metadatos—. Cada objeto hay que alojarlo, y luego recolectarlo. Cuando tienes millones de objetos pequeños —coordenadas, fechas, cantidades— el overhead de memoria y la presión sobre el garbage collector se disparan. Según explica Artur Skowronski en JVM Weekly, es justo el problema que Project Lilliput lleva tiempo atacando por el lado de reducir los headers. Pero Valhalla va a la raíz.

Qué cambia con las value classes

Una value class elimina la identidad del objeto. Dos instancias con los mismos valores en sus campos son indistinguibles, igual que dos int con valor 3 son el mismo 3. Esto le da a la JVM libertad total para almacenar esos objetos de forma plana, sin punteros, en registros o en la pila. La localidad de caché mejora drásticamente y el GC tiene mucho menos trabajo.

El ejemplo canónico es Integer. Hoy, dos Integer con valor 128 no son iguales con == porque son objetos distintos en memoria (para valores <128 Java usa una caché interna, lo que hace el comportamiento aún más confuso). Con JEP 401, Integer migrará a value class y == comparará por valor. Lo mismo para LocalDate y otras clases inmutables del JDK.

Como explicaba Thomas Macaulay en The Next Web, la especificación oficial de JEP 401 deja claro que no es un struct de C#. Java no introduce un nuevo concepto de memoria. Sigues teniendo dos tipos de datos: primitivos y referencias a objetos. Lo que cambia es que algunas referencias apuntan a objetos sin identidad.

Preview, no final: lo que falta

Brian Goetz, arquitecto del lenguaje en Oracle, se apresuró a enfriar los ánimos en Reddit: esto es "solo la primera parte de Valhalla". Eliminar la identidad es la primera barrera y desbloquea optimizaciones importantes para objetos pequeños, pero el tratamiento completo con semántica de valor requiere renunciar a más cosas: nulabilidad y atomicidad bajo condiciones de carrera. Goetz comparó la trayectoria con los structs de C# y advirtió que Valhalla introducirá breaking changes deliberados: código que hoy hace synchronized(integerObject) lanzará excepción cuando Integer sea value class.

JDK 28 llegará en marzo de 2027. JEP 401 vendrá como preview, desactivado por defecto. La siguiente LTS será JDK 29 en septiembre de 2027 y Goetz ya dijo que es improbable que salga de preview para entonces. Lo cual tiene sentido: estamos hablando de cambiar cómo funciona la identidad de objeto a nivel de JVM sin romper miles de millones de líneas de código Java en producción.

12 años para cambiar una línea de código

El proyecto empezó en 2014. Ha sobrevivido a tres arquitectos jefe de Java, dos cambios de ciclo de release, una pandemia y un chiste recurrente en la comunidad: "llegaremos a Valhalla —el paraíso nórdico— antes de que el proyecto llegue a producción". Como apuntaba Skowronski con sorna, "tienes que ganarte a tus propios haters": los que llevaban años diciendo "nunca lo lanzarán" ahora dirán "pero no lanzaron la parte importante".

Yo empecé a programar en Java en 2005 y recuerdo perfectamente el dolor de cabeza de explicar por qué Integer a = 100; Integer b = 100; a == b es true pero con 128 es false. He visto generaciones de developers tropezar exactamente con la misma piedra. Que esto se arregle —aunque sea en preview— es de esas cosas que parecen pequeñas pero cambian el día a día de millones de personas.

La comunidad en Hacker News —542 puntos, uno de los hilos más votados de la semana— lo celebró con un optimismo cauto. Los comentarios más votados señalaban que la migración de Integer es el verdadero test de fuego: si Oracle consigue hacerla sin romper nada, Valhalla habrá demostrado que mereció la espera.

El JEP Café #15 de Oracle —el vídeo oficial que tienes aquí arriba— muestra exactamente cómo se comportan las value classes en la práctica, con ejemplos de código ejecutable. Si tienes 20 minutos, merece la pena verlo entero.