Valhalla llega a Java: qué cambia en JDK 28

Java lleva años cargando con una tensión bastante conocida por cualquiera que trabaja sobre la JVM: quieres escribir código claro, con tipos bien definidos, pero terminas pagando un costo extra en memoria, indirection y objetos que existen más por la forma histórica del lenguaje que por necesidad real. Si tu sistema mueve millones de registros, arma pipelines de datos o vive peleando con GC pauses, ese costo no es teórico. Se nota en latencia, en throughput y en lo fácil que resulta modelar el dominio sin caer en clases de puro relleno.

Project Valhalla apunta justo a ese punto. La idea no es sumar otra moda sintáctica, sino cambiar la base del modelo de tipos para que Java pueda representar datos más cercanos a su forma real de uso: pequeños, inmutables, densos en memoria y baratos de mover. El tema importa ahora porque Valhalla empieza a aterrizar en JDK 28, después de más de una década de trabajo, y eso obliga a equipos que viven en la JVM a entender qué cambia, qué no cambia y dónde sí puede haber impacto concreto.

Qué es Project Valhalla y por qué importa

Valhalla es un proyecto de largo aliento dentro del ecosistema OpenJDK que busca introducir value objects y una nueva forma de pensar el sistema de tipos. Si hoy una clase en Java casi siempre implica identidad, referencia y asignación en heap, Valhalla quiere abrir una segunda vía: tipos que se comporten como valores, no como entidades con identidad propia. Eso suena abstracto hasta que lo conectas con algo tan simple como un punto 2D, una moneda, una coordenada geográfica o un registro de lectura de sensores.

La documentación oficial de OpenJDK explica la dirección general del proyecto y sus piezas principales en el sitio de Valhalla: OpenJDK Project Valhalla. Ahí verás que el objetivo no es reemplazar todo lo que conoces de Java, sino permitir una representación más eficiente y expresiva para ciertos casos. En otras palabras, no estás frente a un cambio cosmético, sino frente a una ampliación del lenguaje y de la JVM.

Para equipos en Latinoamérica que suelen trabajar con plataformas bancarias, e-commerce, logística o fintech, esto tiene una lectura muy práctica. Mucho software empresarial en Java maneja estructuras de datos pequeñas y repetitivas: montos, IDs, pares clave-valor, timestamps, resultados de validación. Hoy muchas de esas piezas terminan modeladas como objetos tradicionales, aunque en realidad no necesitan identidad ni herencia. Ahí es donde Valhalla promete recortar sobrecosto.

El problema que intenta resolver

El problema no es que Java sea lento por definición. El problema es que el modelo clásico de objetos obliga a pagar por cosas que no siempre necesitas. Un Integer en heap, por ejemplo, no es solo el número; también es un objeto con overhead, referencias y comportamiento asociado a la gestión de memoria. Cuando multiplicas eso por cientos de miles o millones de elementos, el costo deja de ser marginal.

En cargas reales, ese costo aparece en tres lugares: más memoria ocupada, más presión sobre el garbage collector y peor localidad de datos en CPU cache. Si tu servicio procesa lotes, serializa eventos o hace agregaciones, esos tres factores pueden pegar fuerte. Valhalla intenta permitir representaciones más compactas y directas, sin obligarte a escribir código en un estilo menos idiomático.

Qué significa “value object” en la práctica

Un value object es un tipo cuyo valor importa más que su identidad. Si dos instancias tienen los mismos datos, para tu lógica son equivalentes. No te interesa si son el mismo objeto en memoria. Eso encaja muy bien con muchos conceptos del dominio: dinero, fechas, coordenadas, medidas, estados simples.

Java ya tiene piezas que se acercan a esa idea, como record, pero un record sigue siendo, en esencia, un objeto tradicional. Valhalla va más profundo porque busca que el runtime pueda tratar esos tipos de forma distinta, con una representación más eficiente y reglas de uso más estrictas. La ganancia no es solo estética; es de modelo y de costo.

Qué cambia en el modelo de tipos

La parte más sensible de Valhalla está en el modelo de tipos. Java históricamente ha mezclado dos ideas en una sola palabra, “objeto”: identidad y datos. Con Valhalla, la plataforma empieza a separar mejor esos conceptos. Eso abre la puerta a tipos que no tienen identidad, que no admiten ciertos patrones clásicos de referencia y que pueden vivir de forma más compacta.

La documentación y el trabajo de diseño en OpenJDK han girado en torno a esa separación entre identity objects y value objects. No hace falta memorizar el vocabulario exacto para entender el impacto: habrá tipos que se comporten más como números o structs que como instancias con identidad. Eso cambia cómo piensas tus APIs, cómo serializas datos y cómo optimizas estructuras internas.

Si hoy diseñas una clase para algo que solo agrupa datos, Valhalla te empuja a preguntarte si realmente necesitas identidad, mutabilidad o herencia. En muchos casos, la respuesta será no. Y cuando esa respuesta es no, el lenguaje te dará opciones más precisas. Eso reduce ambigüedad y también errores de diseño que hoy se esconden detrás de clases “normales”.

Identity objects vs value objects

La diferencia central es esta: un identity object se distingue por su referencia; un value object se distingue por sus campos. Dos Customer distintos pueden tener el mismo nombre y seguir siendo personas diferentes. Dos coordenadas Point(x=10, y=20) con los mismos valores, en cambio, son intercambiables.

Eso parece obvio, pero en Java actual muchas veces terminas tratando ambas cosas con la misma herramienta. Valhalla quiere que esa diferencia quede marcada en el tipo. Para tu equipo, eso puede significar menos ambigüedad y menos bugs por comparar referencias cuando debías comparar contenido.

Por qué esto afecta ergonomía y no solo performance

La parte de performance suele llevarse los titulares, pero la ergonomía también cambia. Si el lenguaje ofrece una forma más natural de expresar datos puros, tu código se vuelve más intencional. No necesitas disfrazar un contenedor de datos como si fuera una entidad compleja solo porque el lenguaje no te daba otra opción.

Eso también ayuda a revisar código. Cuando alguien vea un tipo de valor, entenderá rápido que no debe depender de identidad, ni usarlo como ancla de sincronización, ni esperar semánticas de objeto tradicional. Menos sorpresas, menos reglas implícitas.

Qué puedes esperar en JDK 28

Hablar de “llega a JDK 28” no significa que todo el proyecto ya esté cerrado y listo como una feature clásica. En Java, este tipo de trabajo suele entrar por etapas, con previews, refinamientos y piezas que maduran con el tiempo. Lo que importa es que JDK 28 marca un punto de llegada visible para años de diseño y experimentación.

Si quieres seguir el estado real de la plataforma, conviene mirar el roadmap y las notas de OpenJDK, no rumores de redes. El sitio de Project Valhalla y el seguimiento de JEPs son la referencia más sólida. Un buen punto de partida es la página oficial del proyecto y la documentación de JEPs en openjdk.org. Allí verás qué está en discusión, qué está en preview y qué todavía sigue en evolución.

Para tu equipo, la lectura correcta no es “ya podemos reescribir todo”, sino “ya podemos empezar a entender el nuevo modelo y evaluar casos de uso”. Eso incluye revisar librerías internas, decisiones de modelado y posibles impactos en frameworks, serialización y APIs públicas.

Qué partes del stack pueden sentir el cambio

No todo el stack reacciona igual. Los sistemas más sensibles al layout de memoria, al tráfico de objetos y a la representación de colecciones serán los primeros en notar la diferencia. Piensa en motores de reglas, analítica en tiempo real, trading, procesamiento de eventos y servicios con alto volumen de DTOs.

Frameworks y herramientas también tendrán que adaptarse. ORM, serializers, mappers y bibliotecas de reflexión suelen asumir que todo es un objeto clásico con identidad. Con value objects, algunas de esas suposiciones dejan de ser correctas o pasan a ser optativas.

Qué no cambia de golpe

Valhalla no borra de un plumazo el Java que ya conoces. Las clases tradicionales seguirán existiendo, la compatibilidad seguirá importando y la JVM no va a romper tu base de código por defecto. Si tu aplicación usa Spring, Hibernate, Jackson o una mezcla de bibliotecas maduras, el cambio real será gradual.

Eso sí, gradual no significa trivial. Si tu arquitectura depende de proxies, entidades con lifecycle complejo o serialización muy acoplada a reflexión, tendrás que revisar supuestos. No para correr a migrar todo, sino para evitar diseñar nuevos módulos con ideas viejas cuando ya existe una opción mejor.

Impacto real en memoria y rendimiento

Aquí conviene bajar a tierra. El beneficio de Valhalla no es una promesa vaga de “más velocidad”. El beneficio viene de reducir overhead por objeto, mejorar la densidad de datos y facilitar que la JVM optimice representaciones. En sistemas grandes, eso puede traducirse en menos heap usado y menos presión sobre el garbage collector.

La tabla siguiente resume el contraste conceptual entre el modelo clásico y lo que busca habilitar Valhalla. No son números universales, porque dependen del caso de uso, pero sí sirven para entender la dirección.

En cargas con muchos objetos pequeños, el beneficio puede ser relevante. Por ejemplo, si procesas 10 millones de registros de lectura y cada registro hoy se representa como un objeto tradicional, el costo de administración puede superar al costo de los datos mismos. Con value objects, la JVM tiene más margen para optimizar almacenamiento y acceso.

Ejemplo práctico: datos de negocio repetitivos

Imagina una plataforma de pagos que maneja montos, impuestos, monedas y estados. Hoy podrías tener algo así como Money, Tax, CurrencyCode y PaymentStatus modelados como objetos convencionales. Eso funciona, pero cada instancia trae su costo.

Con Valhalla, ciertos de esos tipos podrían expresarse como valores más compactos, sobre todo si son inmutables y no necesitan identidad. En un sistema que calcula comisiones para miles de transacciones por segundo, la diferencia entre “un objeto por cada campo” y “una representación más densa” no es menor.

Tabla de impacto esperado por caso de uso

No tomes esta tabla como una promesa universal. Tómala como una guía para priorizar dónde mirar primero. Si tu sistema no tiene alto volumen de objetos pequeños, el impacto puede ser modesto. Si sí lo tiene, conviene hacer pruebas tempranas cuando haya soporte estable en tu versión objetivo.

Qué debe revisar tu equipo antes de adoptar

Antes de entusiasmarte con la idea, conviene revisar tu código con una lista concreta. Valhalla no es algo que “se activa” y listo. Requiere entender qué tipos de tu dominio realmente son valores y cuáles son entidades con identidad, mutabilidad y ciclo de vida.

Un buen punto de partida es revisar tres capas: modelo de dominio, APIs públicas y dependencias. Si una clase solo agrupa datos y no tiene comportamiento relevante, puede ser candidata. Si depende de proxies, herencia o sincronización, probablemente no lo sea.

Checklist práctico

1. Identifica tipos que solo transportan datos.
2. Busca clases inmutables que hoy existen por inercia, no por necesidad.
3. Revisa dónde comparas por referencia cuando en realidad comparas contenido.
4. Evalúa serialización, reflection y frameworks que asumen objetos tradicionales.
5. Haz pruebas de carga con datasets grandes antes de cambiar el diseño.

También conviene revisar el uso de record, porque muchas veces ya te resuelve parte del problema semántico, aunque no todo el de representación. Si hoy tu equipo usa record para DTOs, ya está pensando en la dirección correcta. Valhalla amplía ese camino con una base más profunda en la JVM.

Dónde puede haber fricción

La fricción más común vendrá de bibliotecas que hacen magia con clases. ORM, proxies, instrumentación y algunos serializers pueden asumir constructor vacío, identidad estable o mutabilidad. Cuando eso no encaje, tendrás que elegir entre adaptar el tipo o mantenerlo como objeto tradicional.

Otra fricción posible está en la curva mental del equipo. Java lleva décadas enseñando que “todo es un objeto” y que la referencia manda. Valhalla rompe un poco esa costumbre, así que vale la pena documentar bien cuándo usar cada tipo y por qué.

Tabla resumen

Qué significa esto para equipos en Latinoamérica

En la práctica, muchas empresas en Latinoamérica operan con stacks Java que ya están maduros, con equipos pequeños y deuda técnica acumulada. Eso hace que cualquier cambio de plataforma tenga que evaluarse con cuidado. La buena noticia es que Valhalla no pide una reescritura total; pide criterio.

Si trabajas en una fintech en México, una pasarela de pagos en Colombia, un core bancario en Ecuador o una plataforma logística en Chile, probablemente ya tengas zonas donde el modelo de datos está inflado por historia. Ahí es donde esta evolución puede ayudar de verdad: menos memoria por request, menos presión sobre GC y modelos más claros para el equipo.

La clave no es adoptar por moda, sino por costo. Si una estructura vive miles de veces por segundo y solo representa datos, vale la pena seguir de cerca su evolución. Si una entidad tiene identidad, persistencia y comportamiento complejo, no la fuerces a encajar donde no corresponde.

Para seguir la discusión con fuentes primarias, revisa la página oficial del proyecto en OpenJDK y el material de JEPs en openjdk.org. Si tu equipo toma decisiones de arquitectura sobre Java, conviene leer directamente ahí antes de sacar conclusiones de segunda mano.