In JPA, how does the provider decide whether to read and write an entity's state through its fields or through its getters and setters, and why does the placement of the @Id annotation matter for that decision?

## The two access types JPA has to move state between the row and the object. It can do that two ways. - **Field access** (`AccessType.FIELD`): the provider uses reflection on the declared fields — `field.setAccessible(true)`, then get and set. Your getters and setters are never involved in persistence. - **Property access** (`AccessType.PROPERTY`): the provider calls the JavaBean getter to read state and the setter to write it. Every load, every flush comparison, every merge goes through your methods. Which one applies is a per-entity-hierarchy decision, not a per-class whim, and it also determines *which annotations the provider even looks at*. ## How the default is chosen The rule in the specification: the placement of the identifier mapping determines the default access type for the entity hierarchy. If `@Id` (or `@EmbeddedId`) is on a field, the hierarchy defaults to FIELD access and the provider reads mapping annotations from fields. If it is on a getter, the hierarchy defaults to PROPERTY access and the provider reads annotations from getters. This is why the identifier's placement matters far beyond the identifier itself: it silently decides the parsing rule for every other mapping annotation in the class, and for subclasses too. A `@MappedSuperclass` with `@Id` on a field pushes FIELD access down to entities that extend it unless they override it. ## The silent-ignore trap ```java @Entity public class Person { @Id private Long id; // → FIELD access private String firstName; @Column(name = "first_name") // ← on the getter: IGNORED public String getFirstName() { return firstName; } } ``` Nothing fails. The provider simply never inspects the getter, so `firstName` maps to whatever the naming strategy produces from the field name. Depending on the strategy, the column may come out as `firstName` or `first_name` — and the bug surfaces as a schema-validation error or a missing column at runtime, far from the annotation you wrote. The same trap catches `@Enumerated`, `@Temporal`, `@Convert`, `@Lob` and fetch settings. The discipline is: **pick one placement and put every mapping annotation there.** ## Overriding with @Access `@Access` can be applied at class level to state the access type outright — `@Access(AccessType.FIELD)` — which is worth doing when a `@MappedSuperclass` or an `@EmbeddedId` class makes the inferred default non-obvious. It can also be applied to a single member to make just that attribute use the other access type, which is the standard way to run a mostly-field-access entity with one computed, converted or normalized attribute. ## Runtime consequences you should be able to name **Getter side effects.** With property access, Hibernate calls `getX()` during dirty checking at flush and `setX()` while hydrating a row. A setter that trims strings, uppercases, lazily initializes a collection, or fires domain events will run at times you did not choose. A getter that returns `new ArrayList<>(items)` or a defensive copy of a `Date` can make the entity look dirty on every flush, producing a stream of pointless `UPDATE` statements. **Null handling on load.** With property access, a setter that rejects nulls or validates input will throw while Hibernate hydrates a row that legitimately contains a null. Field access sidesteps validation entirely, which is usually what you want for reconstruction from the database. **Proxies and the identifier.** With property access, Hibernate knows the identifier getter method and its proxy can answer `getId()` without hitting the database, because the identifier is already known from the foreign key. With field access, calling `getId()` on an uninitialized proxy runs your own method body, which reads the field and generally forces initialization. (Bytecode enhancement changes this picture, so treat it as a tendency, not a law.) **Encapsulation.** Field access lets you keep the class's public API clean: no setter needs to exist just because a column does, and immutable-ish entities with only business methods are possible. ## Which to choose Field access is the pragmatic default in most codebases, for exactly the reasons above. Property access is worth reaching for when the persisted representation genuinely differs from the in-memory one and you want a method to mediate the translation — though a converter or a single `@Access`-overridden attribute usually expresses that better than flipping the whole entity.