🔓 Open Source
Nadie te dice esto sobre Java 28: los Value Objects llegan a OpenJDK
¿Sabías que Java crea trillones de objetos por día y la mayoría lleva una "etiqueta" de identidad que nadie usa? Eso está a punto de terminar.
El 31 de julio de 2026, OpenJDK fusionó al master el JEP 401: Value Objects (Preview). Sí, el Proyecto Valhalla — esa promesa de más de una década — acaba de dar su paso más grande hasta ahora.
Y no, no es otra función de IA ni una librería de moda. Es una de las transformaciones más profundas que verás en Java en años.
El problema: tu RAM se va en objetos que no necesitan identidad
Desde Java 1.0, todo objeto tiene identidad: una dirección única que permite distinguirlo de otro, aunque ambos tengan exactamente los mismos datos.
¿Para qué sirve la identidad de un LocalDate? Para nada. Es un valor inmutable: el 23 de enero de 1996 es el mismo 23 de enero de 1996, sin importar cuál objeto lo represente.
Pero el JVM igual reserva memoria para esa identidad en cada instancia. Millones de veces por segundo, en tu servidor y en el mío.
Value Objects: la solución que Valhalla prometió hace 12 años
Un value object es un objeto declarado sin identidad. El programador dice explícitamente: "esto es un valor, no una persona en el sistema".
Con eso, el JVM queda libre para guardarlo en la pila, en registros del CPU o incluso inline dentro de arrays. Resultado: menos memoria, menos garbage collection, más velocidad.
La JEP 401 ya convierte en value classes a 30 clases de la API estándar — incluyendo la familia LocalDate y otras inmutables del paquete java.time.
Cómo usarlo: sí, es en JDK 28
La feature llega como preview en JDK 28. Para probarla en tu máquina:
javac --release 28 --enable-preview Main.java
java --enable-preview Main
Y para declarar tu propia clase de valor:
public value class Punto {
private final int x;
private final int y;
}
Sin equals() heroico, sin hashCode() manual, sin defensas de identidad. El compilador y el JVM hacen el resto.
Lo que nadie te dice: hay que re-aprender cosas
No todo es gratis. Los value objects no soportan operaciones sensibles a la identidad: nada de synchronized sobre ellos, ni de compararlos con == esperando direcciones únicas.
Y ojo: no son lo mismo que los records, que llegaron en Java 16. Un record es azúcar sintáctico; un value class es una decisión del JVM sobre cómo representar los datos.
El punto es que dentro de unos años, "objeto con identidad" será la opción pesada que eliges solo cuando de verdad la necesitas — como un hilo, un socket o una conexión.
La opinión de Nox Tech
Valhalla tardó 12 años porque tocar la identidad es tocar la columna vertebral del JVM. Que el JEP 401 esté en master es la señal de que la JVM moderna es una realidad, no un roadmap.
¿El riesgo? Que la mayoría de devs ignore esto hasta que un día una librería "mágicamente" use value classes y el perfil de memoria de su app cambie sin que entiendan por qué.
Empieza a leer el JEP hoy. Tu yo del 2028 — con la factura de RAM en la mano — te lo va a agradecer.
Comparte esto con ese compañero que todavía cree que Java es lento. Y dime: ¿vas a migrar tus inmutables a value classes cuando salga JDK 28, o esperas a que el resto del mundo lo haga primero?