R.I.P Spring Framework (part 1)

The spring framework, Windows and the global economy have something in common. They are all dead but don’t know it yet.

Back in the day, when Sun Microsystems specified J2EE, one of it’s primary goals was to abstract the complexities of scalability and distributed computing within a container and allow enterprise developers to focus on the business logic. Constraints were imposed, essentially to ensure that developers didn’t compromise the application’s ability to scale. As anyone who has developed a framework can attest, protecting developers from themselves is a major consideration since the abilities and understanding of the framework’s clients (i.e. developers) can vary wildly. Those constraints ultimately led to it’s demise as developers looked for ways to work around them. This is where Spring came riding in. It promised more flexibility, running in the web container so EE constraints don’t apply, inversion of control and dependency injection. Powerful xml configuration made short work of complex relationships and disposed of the difficult, incoherent and fragile EJB.

Why is Spring the Zombie of the Java world? The short answer is complexity. If you have recently joined a team that is maintaining an application written using Spring, you will probably already know where this is going. Count how many lines of XML configurations you have. Count how many lines of Java you have. The result is, that spring xml context files have become their own language with significant amounts of logic and code scattered through them. As a developer, you can quickly become lost as you are constantly context switching between Java and XML trying to follow a path through an application. This is all before you start considering aspects.

Complexity is actually the friend of the software industry or at least, contractors. Large volumes of money are involved in ensuring that an application is complex enough to require maintenance and enhancements that are time consuming and regression testing is chargeable line item on the subsequent invoice. Weaving (because that’s a big part of spring coding) a new feature into a large scale spring application can be a hazardous exercise. If applications were clear, coherent and well architected, a lot of people would be out of a job (tongue firmly in cheek).

I am not a spring framework expert and I am deliberately fuelling the flames, but Spring despite it’s popularity has, repeatedly frustrated me to the point of trying out other options on projects where I have a choice.

Java EE to the rescue (again) in part 2.

Leave a Reply