Java’s ‘Everything Is an Object’ Promise Just Died. Here’s What That Means.

If you’ve been writing Java for any length of time, you’ve repeated the mantra without thinking: Everything is an object. It’s the bedrock. The comfort. The thing that makes Java Java. That comfort just got pulled out from under you.

This week, JEP 401 — the value objects (Preview) from Project Valhalla — merged into OpenJDK master. 2,934 commits. A decade of work. And the reaction from most developers? A shrug. A quick glance at the performance gains. A return to their IDEs.

You’re missing the real story.

Valhalla doesn’t just make Java faster. It makes Java fundamentally different.

The core of the change is simple: value objects exist without identity. No heap address. No lock. No == that compares references. They behave like int or double — pure values that are equal if their fields are equal. That’s the performance win. But the hidden cost is that code that relies on object identity will silently break.

Think about it. You’ve synchronized on an Integer? That’s now a value class. Your == check on a Point object? It compares fields, not references. Your weak reference to a String? Gone. The JVM no longer tracks identity for value types.

One developer on the merge thread said: “I do not have a lot of knowledge about the details but from the outset it seems like a rather bold move.” Bold is an understatement. It’s a tectonic shift.

Most discussions focus on the bytecode, the memory layout, the cache misses. But the real disruption is behavioral. Java’s promise of “everything is an object” was always a convenient fiction. Now, the fiction is dead. Value objects are the first nail in the coffin of identity.

You think this is about performance? It’s not. Performance is the side effect. The real story is that Java is finally admitting that “everything is an object” was a lie — or at least, a costly abstraction that forced every int into a box, every Point into a heap cell, every Optional into a reference that could be null. Valhalla fixes that. But it also breaks the mental model of millions of developers.

You’ve been trained to think in terms of references. Now you need to think in terms of values.

This is a bittersweet moment for Java. Exhilarating because Java finally catches up to C# and Rust in memory efficiency. Anxiety-inducing because the ecosystem is not ready. Tools like mocking frameworks, serialization libraries, and ORMs that rely on identity will need to be updated. Code that uses == for comparison will need to be audited. The JVM itself will enforce new restrictions: no synchronized on a value object, no == that compares by reference.

So here’s the question: Are you ready to write code that doesn’t care about identity? Because Valhalla is here, and it’s not going away. The preview flag is the calm before the storm. Start testing. Start questioning your assumptions. And for the love of all that is holy, stop using == on objects you don’t control.

This is the most important change to Java since generics. And most developers are completely unprepared for it.

FAQ

Q: Is this really going to break my code?

A: If you rely on '==' for object identity, synchronize on value objects, or use weak references on classes that become value types, yes. In the preview, you opt in per class, so it's not automatic. But as more standard library classes become value types (e.g., Integer, Optional), your code will break if it assumes identity.

Q: What should I do now to prepare?

A: Start testing with the preview flag (--enable-preview). Audit your codebase for patterns that depend on identity: '==' comparisons on objects, synchronized blocks on value-like objects, and weak/soft references. Use 'equals()' and avoid synchronization on objects that could become value types. Also, check your favorite libraries for compatibility.

Q: Isn't this just a performance optimization?

A: No, it's a paradigm shift. Performance is the surface benefit, but the real change is that Java's abstract model of 'everything is an object' is being replaced by a dual model: identity objects and value objects. This affects how you design data structures, APIs, and even think about equality. It's comparable to the introduction of generics in terms of ecosystem impact.

📎 Source: View Source