In JPA/Hibernate, what does annotating a class @Embeddable and referencing it with @Embedded from another class actually do, and how does such a value type differ from a class annotated @Entity?

## Entities versus value types JPA splits persistent classes into two families. An **entity** has identity: a primary key, its own table row, and a guarantee of one instance per id inside a persistence context. A **value type** has no identity — it is state that belongs entirely to whoever holds it. `@Embeddable` declares a value type; `@Embedded` uses one inside an entity. ```java @Embeddable public class Address { private String street; private String city; private String zip; protected Address() {} } @Entity public class Customer { @Id @GeneratedValue private Long id; private String name; @Embedded private Address address; } ``` This produces **one table**: `customer(id, name, street, city, zip)`. There is no `address` table, no foreign key, no join at read time. `@Embedded` on the field is optional in practice — Hibernate recognises a type annotated `@Embeddable` — but writing it is clearer. ## Consequences of having no identity 1. **No lifecycle operations.** You never `persist()` or `remove()` an `Address`. It is written when the `Customer` is inserted and deleted when the row is deleted. Cascade settings are meaningless for it. 2. **Dirty checking is per column.** Hibernate snapshots the embeddable's columns as part of the owner's state, so `customer.getAddress().setCity("Berlin")` marks the owner dirty and issues an `UPDATE customer SET city=?`. This works only if the embeddable is genuinely mutable and reachable — replacing the whole value (`setAddress(new Address(...))`) is equally fine and usually cleaner. 3. **No shared references.** Two entities must never hold the same `Address` instance. Hibernate has no way to represent sharing (there is no row to point at), so a mutation would be flushed into both owners' rows. Value types should ideally be immutable: final-ish fields, no setters, replace instead of mutate. 4. **Query paths navigate through the attribute** without a join: `select c from Customer c where c.address.city = :city` compiles to a plain predicate on `customer.city`. ## What an embeddable may contain Basic attributes, other embeddables (nesting is allowed to any depth), `@ManyToOne`/`@OneToOne` associations, and even `@ElementCollection`. An embeddable can therefore carry a foreign key column into its owner's table. It can also serve as a composite identifier via `@EmbeddedId`, and as the element type of `@ElementCollection Set<Address>` — both of those uses require a correct `equals`/`hashCode`, whereas a plain `@Embedded` field does not strictly need one. ## Null semantics — the classic gotcha There is no null marker column for an embedded value. When Hibernate reads a row whose embeddable columns are all `NULL`, it hands you `null` for the attribute rather than an `Address` with null fields. So writing a non-null `Address` whose fields happen to be all null and reading it back gives `null` — the round trip is asymmetric. Code defensively, or make at least one column non-nullable. ## Why bother Embeddables buy domain expressiveness at zero schema cost: `Money(amount, currency)` used in five entities keeps the two columns paired and the arithmetic in one class, and `@AttributeOverride` lets each owner rename the columns. They are the JPA answer to "I want a type, not a table".