Project Valhalla, Explicado: Cómo una Década de Trabajo Llega a JDK 28

Alcance y objetivos de Project Valhalla

• El hilo coincide en que los objetivos principales de Valhalla son:
  • Clases valor sin identidad.
  • Diseños más densos y aplanados (especialmente para arrays).
  • Adaptar tipos existentes (p. ej., envoltorios como Integer) como clases valor sin cambios en el código fuente.
• Muchos destacan la dificultad de hacer esto compatiblemente hacia atrás en un ecosistema de 30 años, frente a diseñar structs en un runtime nuevo.

Comparación con .NET, C# y otros lenguajes

• Comparaciones repetidas con los structs de C# y los genéricos reificados:
  • Algunos dicen que Java simplemente está “alcanzando” funciones de .NET ya consolidadas y que el artículo exagera la novedad.
  • Otros sostienen que .NET tenía menos restricciones heredadas; añadir esto al JVM manteniendo ejecutables antiguos funcionando no es trivial.
• Debate sobre fibers/hilos virtuales frente a async/await:
  • Algunos ven los hilos virtuales como estrictamente mejores que las funciones async coloreadas.
  • Otros señalan compensaciones; no hay consenso universal en que sean “objetivamente mejores”.

Debates sobre nullabilidad y sistema de tipos

• Fuerte desacuerdo sobre la falta de seguridad nula integrada en Java:
  • Algunos ven Valhalla como una oportunidad perdida para arreglar null a nivel de tipos.
  • Otros señalan un JEP borrador para tipos restringidos a null (T!) y planes para contextos de “todo no nulo aquí” de grano grueso.
• Disputa sobre si la nullabilidad debería ser una propiedad de los tipos o de las variables.
• Comparaciones con los enfoques de Kotlin, C#, Hack, Go y Rust; no hay consenso sobre el modelo “correcto”.

Semántica: identidad, igualdad y encapsulación

• Las clases valor no tienen identidad; == pasa a ser comparación bit a bit/de estado:
  • Algunos lo celebran; otros temen que filtre la representación interna (por ejemplo, que distintas formas no normalizadas de una fracción comparen como desiguales).
• Integer/Long/Double pasando a ser clases valor:
  • Se reconoce como un cambio disruptivo poco común: el código existente que dependa de la identidad de referencia o de un comportamiento peculiar del boxing puede cambiar o fallar.
• Se aclaró que las clases valor están pensadas para ser inmutables (campos efectivamente final).

Rendimiento, límites del aplanamiento y tearing

• La vista previa actual solo aplana arrays de valores cuya representación de elemento (incluida la bandera de null) quepa en el tamaño de escritura atómica de la plataforma (a menudo 64 bits):
  • Los escépticos dicen que esto limita los beneficios sobre todo a tipos pequeños y primitivos boxed.
  • Los partidarios señalan trabajo futuro (tipos restringidos a null, semántica “tearable”) y que la scalarización de locales sigue siendo útil.
• Preocupa que la scalarización/el aplanamiento puedan fallar de formas opacas, haciendo impredecible el rendimiento; algunos preferirían errores en tiempo de compilación antes que retrocesos silenciosos al heap.

La evolución y custodia de Java

• Sentimiento dividido:
  • Los críticos acusan a Java de sobreconservadurismo, oportunidades perdidas (seguridad nula, diseño de genéricos) y complejidad.
  • Los defensores destacan mejoras rápidas e incrementales (GCs, hilos virtuales, records, sealed types), una fuerte compatibilidad hacia atrás, y sostienen que Java está en su mejor estado de siempre pese al escepticismo de HN.

Meta: calidad del artículo

• Varios comentaristas critican:
  • Prosa e imágenes aparentemente generadas por IA.
  • Inexactitudes técnicas (historia del hardware, ejemplos que ignoran límites de 64 bits).
• Algunos dicen que esto socava la confianza en la explicación, aunque los JEP subyacentes sean sólidos.