When would you choose @Lookup / lookup-method over ObjectFactory/Provider (and vice versa) for obtaining prototype beans?

## Same goal, two styles Both mechanisms let a **long-lived (singleton) bean** obtain a **fresh shorter-lived (prototype) bean** on demand, avoiding the 'resolved once' trap and avoiding direct `ApplicationContext` coupling. ### Method injection: @Lookup / <lookup-method> ```java @Component abstract class OrderProcessor { void process(Order o) { validator().check(o); } // fresh each call @Lookup protected abstract OrderValidator validator(); } ``` - **Call site:** an ordinary method call; no factory type appears in your business code. - **Mechanism:** Spring generates a **CGLIB subclass** overriding the method to call `getBean(...)`. - **Constraints:** class not `final`; method not `final`/`private`/`static`; bean must be CGLIB-instantiable (component-scanned, not a `@Bean` factory method). - **Testing pain:** the bean is effectively abstract; `new OrderProcessor()` won't compile/instantiate cleanly, so you test through the container or override the method by hand. ### Provider style: ObjectFactory / Provider / ObjectProvider ```java @Component class OrderProcessor { private final ObjectProvider<OrderValidator> validators; OrderProcessor(ObjectProvider<OrderValidator> validators) { this.validators = validators; } void process(Order o) { validators.getObject().check(o); } // fresh each call } ``` - **`ObjectFactory<T>`** — Spring interface, `getObject()`. - **`javax/jakarta.inject.Provider<T>`** — JSR-330 standard, `get()` (portable across DI frameworks). - **`ObjectProvider<T>`** — Spring's richer subtype adding `getIfAvailable()`, `getIfUnique()`, `stream()`, and Iterable/Stream support for optional/multiple candidates. - **Mechanism:** just a normal injected bean; **no CGLIB**, no subclassing. - **Constraints:** none of the method-override rules apply; works on any bean, including factory-method beans. - **Testing:** trivial — pass a lambda or mock `ObjectProvider`/`Provider` in a plain constructor call. ## Decision guide | Consideration | Prefer @Lookup | Prefer ObjectProvider/Provider | |---|---|---| | Want call site to look like a plain method | Yes | No (explicit getObject/get) | | Need easy unit testing / no CGLIB | No | Yes | | Bean is created by a @Bean factory method | Won't work | Works | | Need optional/multiple-candidate handling | No | Yes (ObjectProvider) | | Want a JSR-330 portable API | No | Provider<T> | | Class/method must stay final | Won't work | Works | ## Practical recommendation Modern Spring guidance leans toward **`ObjectProvider`** (or `Provider` for portability): it's explicit, testable, CGLIB-free, and handles optional/plural beans. Reach for **`@Lookup`** when you specifically want the lookup hidden behind a normal method (e.g., an existing abstract API you must implement) or in codebases already using that idiom. `<lookup-method>` is the XML equivalent for XML-configured apps. ## Gotcha to remember With **any** of these, the fresh-instance benefit only materializes if the target bean is actually prototype-scoped (or another short scope). If it's a singleton, every `getObject()`/`@Lookup` call returns the same shared instance.