Given an entity instance returned by Hibernate, how do you determine whether one of its associations has already been loaded without causing it to load, and how do you deliberately force it to load or obtain the underlying non-proxy instance?

## Why you need an explicit API An uninitialised association looks exactly like an initialised one from ordinary Java. The field is non-null; the declared type matches; every getter works. The only difference is whether reading it costs a database round trip — and asking the object directly (`x.getName() != null`) *causes* the very load you were trying to detect. So Hibernate exposes an out-of-band way to ask. ## Hibernate.isInitialized ```java boolean loaded = Hibernate.isInitialized(order.getCustomer()); ``` Returns `true` if the argument is a plain entity, an initialised proxy, or an initialised persistent collection; `false` for an unloaded proxy or an unloaded collection. It never triggers loading, and it is null-safe in the sense that a `null` argument counts as initialised (there is nothing to load). The portable equivalent lives on `PersistenceUnitUtil`: ```java PersistenceUnitUtil util = emf.getPersistenceUnitUtil(); util.isLoaded(order); // whole entity util.isLoaded(order, "customer"); // one attribute ``` The attribute form is more useful in practice, because it lets you ask about the *owner's* field rather than needing the possibly-proxy value in hand. ## Hibernate.initialize ```java Hibernate.initialize(order.getLines()); ``` Forces population. Two rules matter: 1. **The session must still be open.** `initialize` is not a way to rescue a detached object; it is a way to decide *when*, inside a live session, the load happens. On a detached instance it fails the same way any lazy access does. 2. **It initialises one level.** Calling it on a collection loads the collection's elements as managed entities, but their own lazy associations remain unloaded. Deep graphs need either repeated calls or, far better, a fetch plan on the original query. The idiomatic use is at the boundary of a service method: while the session is open, materialise exactly what the caller will need. That is a deliberate, readable alternative to relying on the session still being open further out. It is *not* a substitute for a proper fetch plan when you are iterating many parents — one call per parent is precisely the pattern that produces one query per row. ## Hibernate.unproxy ```java Payment p = Hibernate.unproxy(order.getPayment(), Payment.class); ``` Initialises if necessary and returns the real underlying instance. Two situations demand it: - **Downcasting under inheritance.** A proxy is generated for the *statically declared* type. If `Order.payment` is declared as `Payment` and the row is a `CardPayment`, the proxy is a subclass of `Payment` but is **not** an instance of `CardPayment`, so `instanceof CardPayment` returns `false` and a cast throws. Unproxying (or using an explicit query/fetch that loads the concrete type) is the fix. - **Handing entities to code that compares `getClass()`.** Serialisers, `equals` implementations you do not control, and some mapping frameworks compare classes exactly; a proxy's class is not the entity class. Related helper: `Hibernate.getClass(obj)` returns the *entity* class for either a proxy or a plain instance, which is the safe thing to use inside a hand-written `equals`. ## Lazy attributes under enhancement With build-time bytecode enhancement, individual fields can be unloaded. `Hibernate.isPropertyInitialized(obj, "content")` reports on those. `isInitialized` on the entity would say `true` — the entity exists — while a particular column is still absent. ## Diagnostic traps - **Debuggers initialise.** Expanding an object in the variables view calls into it and can populate proxies, making a bug disappear while you look at it. So do `toString()` implementations that print associated state — a good reason to keep `toString` limited to the identifier and simple columns. - **Logging does the same.** A log line at DEBUG that interpolates an entity can silently fire dozens of selects in production. - **`isInitialized` on the wrong reference.** Reading `order.getCustomer()` to pass into `isInitialized` is safe (returning the proxy does not initialise it), but reading any *other* getter on the way is not. ## Where this fits These APIs are diagnostic and boundary tools. Regularly calling `initialize` in application logic is a smell: it means the query did not declare what the use case needs. Use them to *assert* in tests, to unwrap at serialisation boundaries, and to reason about what the query actually fetched.