Project Valhalla in JDK 28: What It Means for Founders

Java doesn't make headlines the way a new AI model drop does. But when a change has been brewing inside the JVM for the better part of a decade and finally lands, it deserves attention—especially from founders whose platforms run on the JVM or whose engineering costs are sensitive to compute efficiency. Project Valhalla, expected to arrive with JDK 28, is exactly that kind of change.

Here's why it matters beyond the compiler team, and what product-minded leaders should take away from it.

What Project Valhalla Actually Changes

At a high level, Project Valhalla introduces value classes to the Java language. Today, every object in Java lives on the heap as a reference type, which means every object carries overhead: a header, an identity, a pointer that the garbage collector has to track. For small, frequently used data structures—think coordinates, monetary amounts, timestamps, ML feature vectors—that overhead adds up fast.

Value classes flatten these objects so they behave more like primitives. They can be inlined into arrays and other objects, removing pointer chasing and drastically improving memory layout. The JVM can pack them tightly, which plays nicely with modern CPU caches.

This is not a cosmetic improvement. It's a structural change to how the JVM represents data in memory, and it has real implications for throughput, latency, and infrastructure cost at scale.

Why Founders Should Care About a JVM Internals Change

If you're a non-technical founder, your instinct might be to file this under "engineering concerns." That would be a mistake. Here's the business lens:

• **Compute cost scales with inefficiency.** If your platform processes millions of small objects—financial transactions, sensor readings, user events, embedding vectors—heap overhead isn't academic. It translates directly into larger instance sizes, more garbage collection pauses, and higher cloud bills.
• **Latency is a product feature.** For real-time applications, recommendation engines, and anything user-facing, GC pauses are the enemy. Value classes reduce the garbage collector's workload by keeping data off the heap or making it easier to manage. Lower latency means better UX, which means better retention.
• **AI-native products are data-dense.** The current generation of AI-powered applications moves enormous volumes of structured numerical data—feature stores, vector databases, inference pipelines. These are precisely the workloads where flattened, cache-friendly memory layout yields outsized gains.
• **It widens Java's competitive envelope.** For years, teams reaching for maximum performance in data-intensive or latency-sensitive contexts would consider Rust, C++, or Go. Valhalla narrows that gap while keeping Java's mature ecosystem, tooling, and developer talent pool intact.

The real story of Valhalla isn't about language syntax. It's about the JVM finally closing the performance gap that has pushed teams toward more complex stacks when Java could have been enough.

The Strategic Implications for Your Tech Stack

For VC-backed companies in growth mode, tech stack decisions have compounding consequences. Choosing the wrong foundation means either costly rewrites later or accepting performance ceilings that limit your product. Valhalla shifts the calculus in a few important ways.

First, it makes the JVM a stronger default for data-heavy products. If you're building a fintech platform, an analytics engine, or an AI-native SaaS product, the JVM ecosystem—Kotlin, Scala, and Java itself—becomes more compelling when the runtime can handle dense numerical workloads without the overhead tax that historically pushed teams toward native languages.

Second, it reduces the need for mixed-language architectures. Today, many teams write their application layer in Java or Kotlin but drop into C++ or Rust for performance-critical data paths. That split introduces build complexity, hiring challenges, and integration risk. If value classes deliver the performance gains the community expects, some of those native components can be consolidated back into JVM code.

Third, it's a signal about the JVM's long-term trajectory. The Java platform has been on an aggressive modernization path—records, sealed classes, pattern matching, virtual threads. Valhalla is arguably the most ambitious piece. Its arrival signals that the JVM is not coasting on legacy momentum; it's actively competing for the next generation of workloads, including AI and real-time data processing.

What This Means for Teams Building Right Now

JDK 28 isn't shipping tomorrow, and even after it does, library and framework ecosystems will take time to adopt value classes fully. So what should you do today?

1. **Audit your data models.** Identify the small, immutable, identity-free types in your codebase—the ones you pass around by the millions. These are your future value class candidates. If you're already using Java records, you're halfway there conceptually.
2. **Design for immutability.** Value classes are inherently identity-free and immutable. Codebases that already favor immutable data structures will have a much smoother migration path. This is good practice regardless of Valhalla.
3. **Evaluate your stack decisions with a longer horizon.** If you're about to make a foundational tech stack choice—say, deciding between a JVM-based stack and a native one for a performance-sensitive service—factor in that the JVM's performance ceiling is about to move meaningfully upward.
4. **Partner with engineers who understand the runtime, not just the language.** The difference between writing Java code and writing Java code that takes advantage of JVM-level improvements like value classes, virtual threads, and modern GC algorithms is significant. Runtime expertise matters.

Building for the Next Generation of JVM Performance

At IDG, we build products on the platforms our clients' businesses actually run on—and for many of them, that's the JVM. Whether we're engineering AI-native products, scalable data platforms, or high-throughput backend systems, we make technology decisions with both current performance and future trajectory in mind.

Changes like Project Valhalla don't happen in isolation. They're part of a broader modernization of the Java platform that intersects directly with the AI and data-intensive workloads we build every day. Understanding where the runtime is headed—and architecting systems to take advantage of it—is part of what separates a product that scales from one that hits a wall.

You can see examples of this thinking in practice across our portfolio. And if you're a founder making foundational tech decisions right now, we'd welcome the conversation. Reach out to our team—we're always happy to talk through what the right architecture looks like for where your product is going, not just where it is today.