Card 04/ 06
BeanFactory vs ApplicationContext
On every axis the application context does more, and one row explains why Spring applications fail fast.
BeanFactory and ApplicationContext are the two interfaces behind Spring's container, the part of Spring that creates beans and hands them out, and ApplicationContext extends the other. The table compares them on the four things that differ; on every one, ApplicationContext does more.
What they share is the core: both create beans, inject their dependencies, and return them from getBean. The rows below are only the differences.
| Axis | BeanFactory | ApplicationContext |
|---|---|---|
| Singleton beans | Created lazily, on first request | Created eagerly, at startup |
| Application events | Not supported | Publishes events and delivers them to listeners |
| Translated messages | Not supported | Built-in message lookup for internationalisation |
| Annotation processing | Only if you register the processors yourself | Registered automatically, so @PostConstruct and @Autowired work |
The first row matters most in practice. Because ApplicationContext creates every singleton at startup, a bean with a broken dependency fails the moment the application starts, instead of the first time something asks for it. That is a large part of why Spring applications tend to fail fast. The events row is the next most useful: booking code can publish a RideBookedEvent, and a notifier bean can listen for it, without either class depending on the other.
The decision rule is short because there is rarely a real choice: use ApplicationContext, which is what Spring Boot gives you. Treat BeanFactory as the interface underneath it, not as a lighter option to reach for.
← → move through sections and cards