Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

Scope and goals of Project Valhalla

• Thread agrees Valhalla’s primary aims are:
  • Value classes without identity.
  • Denser, flattened layouts (especially for arrays).
  • Retrofitting existing types (e.g., wrappers like Integer) as value classes without source changes.
• Many emphasize the difficulty of doing this backward-compatibly in a 30‑year ecosystem, compared to designing structs into a new runtime.

Comparison with .NET, C#, and other languages

• Repeated comparisons to C# structs and reified generics:
  • Some say Java is “just catching up” to long‑standing .NET features and that the article oversells the novelty.
  • Others argue .NET had fewer legacy constraints; adding this to the JVM while keeping old binaries running is non‑trivial.
• Debate over fibers/virtual threads vs async/await:
  • Some see virtual threads as strictly better than colored async functions.
  • Others note trade‑offs; not universally agreed to be “objectively better”.

Nullability and type system debates

• Strong disagreement on Java’s lack of built‑in null‑safety:
  • Some see Valhalla as a missed chance to fix null at the type level.
  • Others point out a draft JEP for null‑restricted types (T!) and plans for coarse‑grained “all non‑null here” contexts.
• Dispute over whether nullability should be a property of types vs variables.
• Comparisons to Kotlin, C#, Hack, Go, and Rust’s approaches; no consensus on the “right” model.

Semantics: identity, equality, and encapsulation

• Value classes have no identity; == becomes bitwise/state comparison:
  • Some welcome this; others worry it leaks internal representation (e.g., different non‑normalized fraction forms comparing unequal).
• Integer/Long/Double becoming value classes:
  • Acknowledged as a rare breaking change: existing code relying on reference identity or peculiar boxing behavior may change or fail.
• Clarified that value classes are intended to be immutable (fields effectively final).

Performance, flattening limits, and tearing

• Current preview only flattens value arrays whose element representation (including null flag) fits into the platform’s atomic write size (often 64 bits):
  • Skeptics say this limits benefits mostly to small types and boxed primitives.
  • Supporters note future work (null‑restricted types, “tearable” semantics) and that scalarization of locals is still useful.
• Concern that scalarization/flattening can fail in opaque ways, making performance unpredictable; some would prefer compile‑time errors to silent heap fallbacks.

Java’s evolution and stewardship

• Split sentiment:
  • Critics accuse Java of over‑conservatism, missed opportunities (null‑safety, generics design), and complexity.
  • Defenders highlight rapid, incremental improvements (GCs, virtual threads, records, sealed types), strong backward compatibility, and argue Java is in its best shape ever despite HN’s skepticism.

Meta: quality of the article

• Multiple commenters criticize:
  • Apparent AI‑generated prose and images.
  • Technical inaccuracies (hardware history, examples ignoring 64‑bit limits).
• Some say this undermines trust in the explanation, even if the underlying JEPs are sound.