JEP 401: Value Objects (Vista previa) se fusiona en OpenJDK master

Artículo original ↗ Discusión en Hacker News ↗

El proyecto de largo recorrido Valhalla de Java ha alcanzado su primer gran hito en OpenJDK: los “value objects” en vista previa, un nuevo tipo de clase sin identidad de objeto diseñado para aportar rendimiento estilo struct sin renunciar a las fuertes garantías de memoria y concurrencia de Java. Los comentaristas lo ven como aproximadamente “la mitad” de Valhalla y la parte más importante, ya que permitirá un mejor uso de los generics y diseños de datos más eficientes, aunque señalan que aún queda trabajo en nullabilidad, generics especializados y tipos de valor desmontables. El cambio también provoca reflexiones más amplias sobre la evolución cauta y compatible hacia atrás de Java, su enfoque en el rendimiento frente a C# y JavaScript, y la distancia entre el lenguaje moderno y su pesado ecosistema empresarial.

Alcance de Project Valhalla y JEP 401

  • JEP 401 (Value Objects, Preview) se ha fusionado; se considera la primera y crucial mitad de Project Valhalla (aproximadamente “~50%” de la visión).
  • El trabajo restante incluye generics especializados, APIs SIMD/vectoriales, generics reificados y tipos no anulables.
  • Muchos comentaristas dicen que esto por sí solo ya convierte a Valhalla en un éxito, especialmente para el rendimiento.

Value Objects: semántica y rendimiento

  • Los value objects se describen como “tipo estructura”: sin identidad, inmutables, aplanables cuando sea posible, con grandes beneficios de memoria y caché.
  • El diseño hace hincapié en la “integridad por defecto”: semántica segura y garantías sólidas, con opciones de rendimiento como opt-ins explícitos.
  • Un marco de diseño divide los datos en cuatro grupos: objetos clásicos, objetos sin identidad, valores atómicos y valores desmontables (“classical”).

Integer, identidad y Strings

  • Integer y envoltorios similares pasan a ser clases de valor, perdiendo la identidad de objeto; muchos señalan que Integer ya se comporta de forma “similar a un valor” por el pooling y hashCode.
  • Los proyectos que dependen de la identidad de Integer han tenido años de advertencia; algunas herramientas de nicho (p. ej., runtimes de lenguajes dirigidos a la JVM) pueden verse afectadas.
  • Los Strings no pueden convertirse en tipos de valor plenamente indistinguibles principalmente por compatibilidad hacia atrás y restricciones técnicas en torno a arrays de respaldo de longitud variable; además, las mejoras se consideran limitadas de todos modos.

Atomicidad, tearability y límites de tamaño

  • La discusión se centra en la atomicidad: las clases de valor no deben “tear” salvo que se marquen explícitamente como tearable.
  • El modelo actual vincula el aplanamiento de referencias al tamaño de palabra de la máquina (p. ej., 63 bits + bit nulo); pueden existir valores mayores, pero no pueden aplanarse de la misma manera.
  • Algunos sostienen que otras plataformas (p. ej., .NET, CPUs con atómicos de 128 bits) muestran compensaciones distintas; otros subrayan que el modelo de memoria de Java y las garantías de seguridad dictan el diseño.

Compatibilidad hacia atrás y migración

  • Hay una fuerte apreciación por la estabilidad a largo plazo de Java: el código antiguo normalmente sigue funcionando sin cambios; los cambios incompatibles son raros, están bien señalizados y son limitados.
  • Ejemplo: sincronizar sobre instancias de Integer acabará rompiéndose cuando se conviertan en value objects.
  • La semántica de valor se define en el sitio de declaración, no en el de uso, para garantizar que la inmutabilidad y la seguridad puedan ser impuestas por la propia clase.

Proceso y gobernanza de OpenJDK

  • La PR aplasta miles de commits en uno mediante un bot; el historial detallado se conserva en herramientas separadas, no en Git.
  • A algunos no les gusta el historial de Git “destruido”; otros sostienen que el proceso es intencional para evitar el bloqueo en GitHub y mantener portables las herramientas externas.
  • Se informa que el trabajo de Valhalla está impulsado de forma abrumadora por Oracle, con elogios por su disciplina y visión a largo plazo frente a la cultura típica de “lanzar pronto”.

Impacto en el ecosistema

  • Se espera que mejore significativamente el rendimiento de Java y de lenguajes JVM de nivel superior como Scala, especialmente donde hoy la abstracción es costosa.
  • Se destacan como futuras grandes mejoras los generics sobre tipos de valor y una mejor especialización del layout.

Lenguaje Java, cultura y comparaciones

  • Muchos expresan un fuerte entusiasmo por Java moderno: records, lambdas, streams, virtual threads, structured concurrency y, ahora, value objects.
  • Varios argumentan que Java ha evolucionado de forma más limpia que C# (visto por algunos como sobredimensionado) y mantiene un modelo más simple (valor vs referencia + Valhalla).
  • La crítica persistente gira en torno a la “cultura empresarial”: frameworks verbosos (especialmente Spring), nombres de clases largos y bases de código enormes; otros responden que esto es cultural, no inherente a Java.
  • Hay menciones positivas de frameworks más ligeros (p. ej., Helidon, Quarkus) y de diseños centrados en virtual threads.
  • Java se contrasta repetidamente con JavaScript: sintaxis superficial similar pero objetivos muy distintos; Java se ve por delante en funciones como fecha/hora modernas, expresiones switch y, ahora, value objects.

Herramientas y CLI

  • Algunos desearían una CLI unificada, más “baterías incluidas” y similar a Go, para build/test/format/lsp, en lugar de la fragmentación actual (Maven, Gradle, etc.).
  • Maven es apreciado por su estabilidad, pero se critica su XML y su modelo de actualización; Gradle se ve como potente pero sensible a la versión.