Why is class weaving important for lazy loading in EclipseLink?

Standard Java has no built-in way to intercept field access on a plain object, which is exactly what transparent lazy loading needs: the ability to notice when a @OneToMany or @ManyToOne relationship is actually accessed and only then go fetch it. Weaving solves this by rewriting the entity's bytecode to route field access through EclipseLink-managed indirection.

Without weaving, a lazy @OneToMany collection still has to be represented by something before the real data is fetched. EclipseLink falls back to wrapping it in an IndirectList or similar indirection object that transparently triggers a query the first time the collection is actually iterated or its size is checked, but this fallback is less efficient than weaving-enabled indirection and, more importantly, only works for relationship attributes, not for basic (non-relationship) attributes, which is where fetch groups depend specifically on weaving to defer loading.

Practically, this means an application that disables weaving, intentionally or by misconfiguration, loses the performance benefit of fetch groups and attribute-level change tracking even if lazy relationships still technically function through the older indirection fallback.