Inversion of Control, Built in Miniature

"We are not makers of history. We are made by history." — Martin Luther King Jr., Strength to Love (1963)

Spring is the reason most Java jobs exist, and it is the part of Java that most often gets learned as incantation: annotate the class, inject the field, and something somewhere makes it work. That is a bad position to be in during an interview, and a worse one at three in the morning when the something has decided not to.

So this part does not start with Spring. It starts by building a container — a real one, small enough to read in a sitting, that scans classes, resolves dependencies by type, caches singletons, detects cycles and runs lifecycle callbacks. Roughly sixty lines. Once you have written that, @Autowired stops being magic and becomes an obvious consequence, and the questions interviewers ask about it — why is my bean null, what happens with two implementations, what does a circular dependency actually mean — turn into questions about code you have already written.

A note on this playground. Spring itself needs a servlet container, a classpath scanner and a database that a browser cannot provide, so Spring's own jars are not here. Everything below is plain Java 17 and runs. The reflection the real container uses — runtime annotations, constructor discovery, setAccessible, java.lang.reflect.Proxy — all works here, which is why the miniature is a genuine model rather than a sketch.

The problem, stated honestly

Before the solution, the thing it replaces. Here is an object graph wired by hand.

Nothing in that main is interesting. Every line is forced: SqlRepo needs a Clock, so a Clock must exist first. You are performing a topological sort mentally, in a file edited every time a constructor changes.

The one genuinely interesting decision is hidden in the middle — audit and repo share a Clock. That is a sharing decision, invisible in the types, and getting it wrong with a connection pool rather than a clock is how applications end up with two pools and half the connections they think they have.

Inversion of control is the observation that the mechanical part is derivable. The types already say what each object needs. Something could read them and do the sort for you — and then the sharing decision becomes a declaration rather than an accident of which line you wrote.

A container, in about sixty lines

Here is the whole idea. Register some classes; ask for one; get a fully-wired object graph.

Read instantiate again, because it is the entire mechanism: look at the constructor, ask what types it wants, build each of those the same way, then call the constructor. The recursion performs the topological sort, which is why registering in reverse order produces the identical construction sequence.

And notice what the application classes do not do. None of them mentions MiniContext. None imports it. They declare their dependencies as constructor parameters — which is what they would do anyway — and the container reads that declaration. That is the inversion: the objects no longer control how they are assembled, and they did not have to be changed to give that up.

The real ApplicationContext is this, plus about fifteen years of edge cases. The core loop is the same.

Singletons, and why identity is the point

The container so far rebuilds everything on every request. Real containers cache, and that cache is not an optimisation — it is the sharing decision from the first block, made explicit.

The two pool counts are the chapter's most practical output. Without the cache, a service's repository and its audit log each get their own ConnectionPool — the application works, the tests pass, and in production you have twice as many pools as you budgeted for and half the connections per pool. With the cache, there is one.

That is why singleton scope is the default, and it is also where the most-missed consequence lives: one instance serves every request on every thread. A @Service with a mutable field is shared mutable state between concurrent requests, which is precisely the hazard of Part IV. Dependencies belong in final fields assigned in the constructor; anything about this particular request belongs in a method parameter or a local.

The three failures, and why good messages matter

A container that only works when everything is right is not worth much. Most of a real container's code is about telling you what went wrong.

Three failures, three messages, and the wording above is close to what Spring actually prints — NoSuchBeanDefinitionException and NoUniqueBeanDefinitionException are messages you will read many times, and they are now messages you know how to generate.

The cycle is the one worth understanding properly. With constructor injection a cycle is not difficult, it is impossible: OrderService cannot be constructed until BillingService exists, and vice versa. No amount of container cleverness fixes that, because it is arithmetic.

Field injection appears to solve it, and that is the real argument against field injection. Because a field is set after the object exists, a container can construct both halves and patch the references in afterwards — so the cycle survives as a design problem you can no longer see. Spring Boot 2.6 made cycles fail by default for exactly this reason. Constructor injection is preferred not mainly because it allows final fields and easy testing, but because it makes an impossible design impossible to express.

The payoff: substitution

The wiring is the visible benefit. Substitution is the one that actually changed how Java is written, and it costs nothing extra once the inversion is in place.

The last section is the whole argument compressed. new UserService(id -> "inline-" + id) constructs the service with a lambda standing in for the repository — no container, no mocking framework, no configuration. That works only because UserService declares its need as an interface parameter and never constructs a SqlRepo itself.

This is the property EJB lacked. A component that can only be obtained from a container can only be tested inside one, which in 2002 meant deploying to an application server to run a unit test. Spring's classes are plain classes with constructors, so the fast test is the default and the container is an optional convenience. The wiring was the feature people noticed; the testability is what changed the industry.

Note also that StubRepo recording its calls is a mock — Mockito generates that for you, but nothing about it requires a library. The seam is the interface, and the interface was already there.

What the real thing looks like

The miniature maps onto Spring almost name for name.

// Real Spring. Same graph, same wiring, same lifecycle.

@Component                                     // a bean definition, found by scanning
class SqlRepo implements Repo {
    private final Clock clock;
    SqlRepo(Clock clock) { this.clock = clock; }   // no @Autowired needed on a single constructor
}

@Service                                       // @Component with a stereotype name
class UserService {
    private final Repo repo;
    UserService(@Qualifier("sqlRepo") Repo repo) { this.repo = repo; }
}

@Configuration                                 // beans the container cannot construct itself
class AppConfig {
    @Bean Clock clock() { return Clock.systemUTC(); }
    @Bean @Primary Repo preferredRepo(Clock c) { return new SqlRepo(c); }
}

var ctx = new AnnotationConfigApplicationContext("com.example");
UserController controller = ctx.getBean(UserController.class);

The pieces, against what you just built:

• @Component is register(), except Spring finds the classes itself by scanning a package. @Service, @Repository and @Controller are @Component with a name that documents intent — and @Repository additionally translates persistence exceptions.
• The constructor is the injection point. Since Spring 4.3, a class with exactly one constructor needs no @Autowired at all; the annotation is only required to pick between several.
• @Bean methods in a @Configuration class cover what scanning cannot: types you do not own, like a DataSource or a third-party client. They are factory methods the container calls, and their parameters are injected the same way.
• @Primary and @Qualifier are the ambiguity resolution you implemented — a default, and a selection by name.
• getBean is get, and AnnotationConfigApplicationContext is MiniContext with the scanner attached.

One thing the miniature does not model: Spring instantiates all singletons eagerly at startup, not lazily on first getBean. That is a deliberate choice — it means a missing bean, an ambiguous type or a cycle fails at startup rather than on the first request.

Common Mistakes

1. Putting request state in a @Service field. One singleton serves every request on every thread; a mutable field is shared mutable state.

2. Creating a managed class with new. The container never saw it, so nothing is injected and no annotation applies.

3. Expecting a bean outside the scanned packages to be found. Scanning starts at the application class's package and descends.

4. Using field injection to break a cycle. It hides an impossible design rather than fixing it, which is why Boot 2.6 disallows cycles by default.

5. Adding @Autowired to a single constructor. Unnecessary since Spring 4.3 — it is only needed to choose between several constructors.

6. Injecting a concrete class where an interface is meant. It works, but removes the seam for a test double or a proxy.

7. Reaching for @Qualifier before @Primary. A sensible default serves most call sites; qualify only the exception.

8. Assuming @Component works on a type you do not own. You cannot annotate a library class — that is what @Bean methods in a @Configuration class are for.

9. Treating the container as a service locator. Injecting ApplicationContext and calling getBean re-couples the class to the framework and discards the inversion.

10. Thinking singleton scope means thread-safe. It means precisely one shared instance, which is the opposite guarantee.

Interview Corner

Hands-on

Summary

• A container reads constructor parameter types and builds the graph depth-first — the recursion is the topological sort, so registration order is irrelevant.
• The inversion is that your classes never mention the container. They declare dependencies as constructor parameters, which is what they would do regardless.
• Singleton scope is one Map lookup, and it exists to make the sharing decision explicit rather than accidental.
• One instance serves every request on every thread. Dependencies in final fields; request state never in a field.
• A constructor cycle is unsatisfiable, not merely awkward — neither object can exist first, which is arithmetic rather than a container limitation.
• Field injection hides cycles by patching references after construction, which is the strongest argument against it; Boot 2.6 disallows cycles by default.
• @Primary is a default and @Qualifier is a selection — both are filters applied when more than one candidate matches.
• @Bean methods cover what scanning cannot: types you do not own, constructed by a factory method the container calls.
• Spring instantiates singletons eagerly at startup, so missing, ambiguous and circular beans fail before the first request.
• Annotations only act on objects the container made. Anything built with new is unmanaged, which explains most "why is my bean null".

You now have a container that constructs beans. The next chapter is about everything that happens to a bean between construction and use — the scopes beyond singleton, the lifecycle callbacks, and the post-processors that are the hook every other Spring feature is built on.