Why Spring Exists: Tracing Java’s Framework Evolution and Core Principles

1. Knowing History Can Enlighten

Learning technology without understanding its history leads to confusion about why a framework exists and how it solves problems. Many developers jump straight to Spring Boot without grasping the evolution of web development that gave rise to Spring.

2. Brief History of Web Development

The development of web applications can be divided into four stages:

Initial stage: Model1/Model2 and three‑tier architecture.

Middle stage: EJB for distributed applications, with heavy weight.

Advanced stage: Spring, offering powerful features but requiring extensive configuration.

Bone‑marrow stage: Spring Boot, emphasizing "convention over configuration".

3. Early Stage: Model1 and Model2

Model1 Development Mode

Model1 follows a JSP + JavaBean pattern where JSP pages handle both view rendering and business logic, leading to tightly coupled code that is hard to maintain.

Model2 Development Mode

Model2 introduces Servlet to separate request handling from view rendering, forming a true MVC architecture (JSP + Servlet + JavaBean).

Differences Between Model1 and Model2

Model1: Simple, suitable for small projects, but JSP handles both view and controller, causing high coupling.

Model2: Clear separation of responsibilities, better for large projects, but still not a complete MVC solution.

Comparison with Three‑Tier Architecture

Three‑tier adds distinct layers for presentation (JSP/Servlet), business logic, and persistence, further reducing coupling.

4. Mid, Advanced, and "Bone‑Marrow" Stages

The middle stage involved EJB, which many developers find cumbersome. The advanced stage introduced Spring, inspired by Rod Johnson’s critique of heavyweight J2EE frameworks. The bone‑marrow stage is Spring Boot, which streamlines configuration.

5. Problems in the Early Stage

Interface‑Based Instantiation

Using interfaces leads to repeated object creation, increasing garbage collection pressure.

UserDao userDao = new UserDaoImpl();

Singleton Pattern Attempt

Applying the singleton pattern reduces object creation but introduces tight coupling and repetitive template code.

Pain Points

Developers need a solution that avoids both excessive object creation and boilerplate singleton code.

6. Proposed "Object Pool" Concept

Store interface implementation objects in a pool and retrieve them as needed, similar to how Spring’s IoC container manages beans.

7. Spring IoC Overview

Spring reads configuration or annotations, creates singleton beans, and places them in the container, providing dependency injection and inversion of control.

8. Conclusion

Understanding the historical problems that led to Spring helps appreciate its design, the benefits of IoC, and prepares developers for deeper topics such as AOP.