2 Data, Identity, and Values

The chapter introduces a data-oriented way of thinking about Java by separating identity, values, and data. Identity is described as continuity over time: a variable or object can hold changing states while still being treated as the same thing, but that continuity is a modeling choice rather than a property of the data itself. Values, by contrast, have no meaningful identity and cannot change; they are defined entirely by their state, and any two values with the same state are interchangeable. This distinction matters because data-oriented programming aims to represent information without relying on mutable object identity.

From there, the chapter explains that data is simply a value plus meaning. A number like 4 becomes data when it is understood as a temperature, age, or other domain concept, and the representation chosen in code communicates important semantics to the reader and the compiler. Java records are presented as the main tool for modeling such values and data: they provide concise, transparent carriers of state, support validation and normalization through compact constructors, and make it easier to define rich domain types with clear intent. The chapter emphasizes that records should be built from immutable components, because mutability can quietly undermine value semantics.

The final part focuses on practical modeling concerns, especially how to preserve value behavior in real Java programs. Collections can be treated as values when they are made unmodifiable, but mutable references inside them can “poison” the whole structure and reintroduce identity-like behavior. Nulls are treated similarly as a threat to trustworthy data modeling, since they weaken the contract that a type should always mean what it says. The chapter closes by showing how records improve readability, enable local data types, and help older Java codebases approximate value modeling through tools like Lombok and Immutables, all in service of the chapter’s central message: good data modeling is about making semantics explicit and keeping values pure.

Comparing semantic levels

Simulating a ball being tossed. The object is a useful abstraction, but the idea of a ball exists on its own

Looking at the succession of values inside of an object

A succession of values laid out on a timeline

Data Oriented updates

The record class

Comparing traditional versus compact constructors

• Identity gives continuity to a related set of values as they change over time
• Object identity is the most tangible in Java. It shapes “how” we usually program.
• Variables create an identity that associates values over time with a named location
• Values just are. They transcend our programs. They’re immutable and unchanging.
• Values have no notion of identity.
• Value objects are how we represent values in Java
• Value objects carry the same properties as the values they model: immutable and defined by equality
• A value assigned to a non-final variable is not a value (though, we ignore this and manage by convention)
• All Java collection types can be used to model values. It just requires care to ensure the correct semantics
• Data “as data” means modeling data as values
• Values become data when we give them meaning or context.
• Data is more than collections of facts. It can model abstract ideas, or decisions, or state itself
• Data can model identity and change over time. We model this by creating a succession of values
• Records are modeling tools for creating value and data objects
• Records have a compact constructor, which lets us skip a lot of the ceremony of traditional constructors
• The validation we put in record constructors guards the value’s semantics
• Transformation of incoming constructor arguments can be used to enforce specific value semantics
• The terseness of records enables us to introduce new semantic layers into program with minimal overhead
• The terseness of records also allows us to leverage new code layout strategies.
• Annotation processors like Lombok and Immutables can generate value classes on older JDKs

FAQ