Ten years that did not shake the Spring Framework

Today I happened to realize that it has been quite a few years, ten to be precise, since I first encountered this venerable technology. In 2004, quite a few developers believed that the only right way to build applications was to follow Java EE, then still called J2EE. I'll use the current name for the rest of this article. Like every other supposedly right path, it was not entirely right, as the last ten years have shown. I will try to explain the historical context in which the Spring Framework arose and outline why, even as application architecture has changed, it remains a viable tool and a de facto standard for Java development.

To understand the context and the origins of Spring, we have to go back to the turn of the millennium. The dot-com bubble was at its peak and the share prices of tech companies such as Sun were soaring. To borrow a line from Ivan Horník, infamous for a football corruption scandal, there was no shortage of ammo, mate, and money was pouring into development. Sun, and probably others including Microsoft, came up with the idea of a platform for developing enterprise applications at the pace of a Ford assembly line. Developers would be on one side and middleware vendors, meaning application server vendors, on the other. A standardized platform would sit between them, with a contract in the form of APIs and specifications. This arrangement was supposed to make applications easily portable and create competition among server vendors. It was a good idea, but it had plenty of problems in practice.

For a start, Java EE was designed as a family of interdependent technologies. If you wanted to use Enterprise JavaBeans, for example, you had to learn related technologies such as the Java Transaction API. Another problem was that Java EE essentially dictated your application architecture. Its designers assumed one size would fit all and that every application would have much the same needs. They could hardly have imagined what kinds of applications people would build once the internet spread widely just a few years later. Around 2002, the first wave of frustration with Java EE began. That was when J2EE Design and Development, an important book by Spring Framework creator Rod Johnson, appeared. Johnson tried to offer a recipe for using Java EE properly, including a “framework” he developed for the purpose. Interestingly, the book's source code, some 30,000 lines, later became the foundation of Spring. Johnson identified exactly what people were struggling with, and the book was a great success.

The main idea was to make applications easy to develop, test and deploy. In technical terms, this meant using a few simple patterns that already existed. Inversion of Control managed relationships between objects. Template Method isolated frequently repeated code. Aspect-oriented programming handled concerns that cut across the application. Johnson's experience with Java EE taught him that the whole solution had to impose as little as possible on its users. Spring was therefore modular from the beginning. Use what you need. Developers did not have to bend their application architecture to fit the framework. The framework was like a set of Lego bricks you could take what you needed from.

You can find that philosophy and those three patterns in any other project built in the Spring ecosystem. Spring was never rocket science. The magic lay in how elegant it was to use, and the elegance came from simplicity. It was by the book. A framework should solve recurring problems and make life easier for application programmers. Nothing more, nothing less. That is why Spring has survived the past ten years in essentially the same form, without dramatic twists or changes.

Application architecture changed in interesting ways over that time. Monolithic architecture was common for a long time, a euphemism for one big ball of tangled spaghetti. It began to change slowly, then smart mobile devices sped things up. Suddenly you had to support a whole range of devices, including phones and tablets, alongside the web browser. Social networks and app stores made it easy to reach large numbers of users cheaply. Everyone needed, or was told, to develop applications at lightning speed. The cloud offered one way to cut the time it took to get an application to the customer.

Enterprise applications ran on purchased, reliable hardware tucked away in bank and corporate data centers, while a growing family of applications ran on what you would call commodity hardware. Applications took months or weeks to build instead of years. Success often brought scalability and stability problems. Those problems had existed before, but they came up much less often. Over the last two years we have seen architecture shift from monoliths toward applications built on microservices running in the cloud, private or public. If the ratio today is 80/20 in favor of monoliths, it could reverse for new applications within two years. If I set out to build a microservices application today, I would ask for the same things as in 2004: easy development, testing and deployment. It might not sound sexy enough to tech hipsters, but Spring, that ten-year-old technology, gives me exactly that. I am talking about code whose dependencies I describe with annotations, where I use convention over configuration. Each microservice uses a REST interface and client or communicates through messaging. In both cases it runs in a Spring Boot container.

Spring has come a long way in ten years. For many people, it is a technology that changes very little and that almost everyone knows. They're right. Spring has always rested on simple concepts that worked well and pleased developers. Let's hope it sticks with that philosophy. That is what lets it meet the needs of application architectures that differ radically from those around when it first appeared. What wouldn't other technologies give for that?