JEP 401: Value Objects (Preview) merged to OpenJDK master

Original Article ↗ Hacker News Discussion ↗

Java’s long-running Project Valhalla has landed its first major milestone in OpenJDK: preview “value objects,” a new kind of class without object identity designed to bring struct-like performance while preserving Java’s strong memory and concurrency guarantees. Commenters see this as roughly “half” of Valhalla and the most important part, enabling better use of generics and more efficient data layouts, while noting remaining work on nullability, specialized generics, and tearable value types. The change also prompts broader reflections on Java’s cautious, backwards-compatible evolution, its performance focus compared to C# and JavaScript, and the gap between the modern language and its heavyweight enterprise ecosystem.

Project Valhalla & JEP 401 Scope

  • JEP 401 (Value Objects, Preview) is merged; seen as the first, crucial half of Project Valhalla (roughly “~50%” of the vision).
  • Remaining work includes specialized generics, SIMD/vector APIs, reified generics, and non-nullable types.
  • Many commenters say this alone already makes Valhalla a success, especially for performance.

Value Objects: Semantics & Performance

  • Value objects are described as “struct‑like”: no identity, immutable, flattenable where possible, with big memory and cache benefits.
  • Design emphasizes “integrity by default”: safe semantics and strong guarantees, with performance options as explicit opt‑ins.
  • One design framing splits data into four buckets: classic objects, identity‑less objects, atomic values, and tearable (“classical”) values.

Integer, Identity & Strings

  • Integer and similar wrappers become value classes, losing object identity; many note Integer already behaves “value‑like” due to pooling and hashCode.
  • Projects relying on Integer identity have had years of warning; some niche tools (e.g., language runtimes targeting the JVM) may be impacted.
  • Strings cannot become fully indistinguishable value types mainly due to backward compatibility and technical constraints around variable-length backing arrays; gains are seen as limited anyway.

Atomicity, Tearability & Size Limits

  • Discussion centers on atomicity: value classes must not “tear” unless explicitly marked tearable.
  • Current model ties reference flattening to machine word size (e.g., 63 bits + null bit); larger values can exist but not be flattened the same way.
  • Some argue other platforms (e.g., .NET, CPUs with 128‑bit atomics) show different tradeoffs; others stress Java’s memory model and safety guarantees dictate the design.

Backward Compatibility & Migration

  • Strong appreciation for Java’s long‑term stability: old code typically runs unchanged; breaking changes are rare, well‑signposted, and narrow.
  • Example: synchronizing on Integer instances will eventually break when they become value objects.
  • Value semantics are declaration‑site, not use‑site, to ensure immutability and safety can be enforced by the class itself.

OpenJDK Process & Governance

  • The PR squashes thousands of commits into one via a bot; detailed history is preserved in separate tooling, not in Git.
  • Some dislike the “destroyed” Git history; others argue the process is intentional to avoid GitHub lock‑in and keep external tooling portable.
  • Valhalla work is reported as overwhelmingly driven by Oracle, with praise for its discipline and long‑term vision compared to typical “ship early” culture.

Impact on Ecosystem

  • Expected to significantly improve performance for Java and higher‑level JVM languages like Scala, especially where today abstraction is costly.
  • Generics over value types and better layout specialization are highlighted as future big wins.

Java Language, Culture & Comparisons

  • Many express strong enthusiasm for modern Java: records, lambdas, streams, virtual threads, structured concurrency, and now value objects.
  • Several argue Java has evolved more cleanly than C# (seen by some as overcomplicated) and keeps a simpler model (value vs reference + Valhalla).
  • Persistent critique is around “enterprise culture”: verbose frameworks (esp. Spring), long class names, and massive codebases; others counter that this is cultural, not inherent to Java.
  • Positive mentions of lighter frameworks (e.g., Helidon, Quarkus) and virtual‑thread‑centric designs.
  • Java is repeatedly contrasted to JavaScript: similar surface syntax but very different goals; Java seen as ahead on features like modern date/time, switch expressions, and now value objects.

Tooling & CLI

  • Some wish for a more batteries‑included, Go‑like unified CLI for build/test/format/lsp, instead of the current fragmentation (Maven, Gradle, etc.).
  • Maven is appreciated for stability but its XML and upgrade model are criticized; Gradle is seen as powerful but version‑sensitive.