Project Valhalla llega a JDK 28: doce años para cambiar cómo Java trata los tipos

Project Valhalla lleva en el horno de OpenJDK desde 2014. Doce años después, con un pull request de 197.000 líneas de código en 1.816 ficheros modificados, la primera pieza del proyecto ha aterrizado en el mainline de OpenJDK con destino a JDK 28: JEP 401 — Value Classes and Objects. Es el cambio estructural más grande que Java ha acometido en una década, y conviene entenderlo antes de que llegue como preview en JDK 28 (previsto para marzo de 2027).

El problema que Valhalla viene a resolver

Java heredó de sus orígenes una división que lleva décadas siendo una fuente de dolor: por un lado los primitivos (int, long, double...) que son rápidos porque se guardan por valor, se copian, no tienen identidad y se comparan con ==; por otro las clases, que se acceden siempre a través de referencias, tienen identidad de objeto y se comparan con equals(). Para usar primitivos en colecciones genéricas, Java los tiene que envolver en objetos (Integer, Long...) con el coste de memoria y GC que eso supone.

Project Valhalla quiere cerrar esa brecha. La idea es permitir tipos que se comportan como primitivos (sin identidad, comparados por valor, guardados de forma contigua en memoria) pero que tienen la expresividad de las clases: campos, métodos, genéricos.

Quien haya seguido la evolución reciente del lenguaje reconocerá el patrón: Project Loom trajo los virtual threads a Java 21 después de años de trabajo y cambió radicalmente cómo se escribe código concurrente. Valhalla apunta a hacer algo parecido con el sistema de tipos.

Qué son las Value Classes (JEP 401)

Con JEP 401 puedes declarar una clase como value:

value class Point {
    int x;
    int y;

    Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
}

Una value class tiene estas características:

• Sin identidad de objeto. No puedes usar == para comparar dos instancias: el compilador te obliga a usar equals(). Tampoco puedes sincronizar sobre una value class ni usar su referencia como llave de IdentityHashMap.
• Comparación por valor. Dos instancias con los mismos campos son indistinguibles, igual que dos int con el mismo número.
• Scalarización. El JIT puede descomponer una value class en sus campos individuales y trabajar con ellos como si fueran primitivos, sin crear un objeto en el heap.
• Flattening. Un array de value classes se puede guardar de forma contigua en memoria, sin punteros intermedios. Esto mejora el rendimiento de caché de forma significativa.

Qué cambia en las clases existentes

Parte de JEP 401 es la migración de las clases «value-based» ya existentes en el JDK a value classes bajo preview. Eso incluye los wrappers de primitivos: Integer, Long, Double y compañía. Cuando esto se estabilice, List<Integer> podrá guardarse internamente como si fuera List<int>, sin el coste de boxing.

También se introduce el concepto de value records: la combinación de record (que ya teníamos desde Java 14) con la semántica de value class.

Para el contexto de los cambios modernos del lenguaje que llevan varios releases, el artículo sobre Java moderno en 2026 cubre records, sealed classes y pattern matching, que son las piezas del puzzle que preceden a Valhalla.

Lo que NO llega en JDK 28

JEP 401 es la primera pieza, no todo Valhalla. Lo que queda fuera de JDK 28:

• Null-restricted types. La capacidad de declarar que una variable no puede ser null (Point! en la sintaxis propuesta) forma parte de JEP 402 y no llegará en JDK 28.
• Specialized generics. Poder escribir List<int> directamente, sin boxing, requiere cambios en el sistema de generics que van más allá de JEP 401.
• Encodings de 128 bits. Tipos que quepan en registros de 128 bits tampoco están en esta primera entrega.

Cómo probarlo ahora

La feature está bajo la bandera --enable-preview, así que no está disponible por defecto. Para experimentar:

javac --enable-preview --release 28 MiClase.java
java --enable-preview MiClase

Las early access builds de JDK 28 están disponibles en jdk.java.net/28. El equipo pide explícitamente feedback sobre el comportamiento de scalarización y flattening en código real, así que si tienes código con muchos objetos pequeños es un buen momento para probarlo.

Cuándo llegará estable

JDK 28 se espera en marzo de 2027 y no es una versión LTS. La siguiente LTS será JDK 29, prevista para septiembre de 2027. Esperar a que JEP 401 salga de preview en JDK 29 es la apuesta más segura si planeas usarlo en producción.

Para entender cómo Java gestiona sus versiones LTS y cuál deberías usar hoy, el artículo sobre Java en 2026: versiones LTS y ciclo de releases lo explica con detalle.

Imagen: Pexels / Daniil Komov