Spring sucks? Refuting the case against Spring

XML is the devil

There have been many complaints about how much XML is required to create a Spring application. Developers who complain about this may not be aware that Spring has presented a choice between XML and annotations for a number of years. In fact, there is now a choice between those formats and a Java-based format similar to Google Guice or other code-based injection APIs.

Too many JARs

Another oft-used argument is that Java EE provides everything you need, out of the box. In the most recent Philly Emerging Technologies Web Framework Shootout, held in the spring of 2011, a Java EE panelist complained loudly that the team had to pull in a ton of JARs just to build their projects in Spring. The best answer was made by SpringSource's Jeremy Grelle, who said something to the effect of "Is that all you've got?"

Enterprise software should not be constrained by what comes with the product. Integration with other technologies is a key activity, and Java developers are very innovative. Developers often have to go outside of the box to select a new API -- such as the newest hot JSON parser, Web framework, view technology, et cetera -- to meet a custom need. In this common situation, there will always be a need to find some external API and integrate it.

Saying that Spring shouldn't be used because it doesn't have the "approved, built-in" APIs and uses something outside of that box is old thinking. We shouldn't be forced to box ourselves into a corner. We should be able to select libraries that give us the best combination of features, compatible licensing, a rich developer community and support. In short, Spring and all other enterprise APIs -- either from Java EE or any of the open source forges, such as Eclipse or Apache -- should be available to the developer.

Spring code is not Java EE standard code

Sure, you can program perfectly portable Java EE code and run it in any container. You can also select the Spring APIs where necessary, and you'll be constrained to run in the Spring container. However, with the popularity of Spring in the enterprise, picking a Spring API to use won't be a bad bet generally.

Where possible, the Spring team has written itself out of the equation. For example, before Hibernate supported the sessionFactory.getCurrentSession API, SpringSource recommended using the HibernateSupportDAO and HibernateTemplate APIs, which would automatically set up and tear down connections to Hibernate. Now that Hibernate supports ThreadLocal connections and can be integrated behind the scenes into transaction support in Spring, developers are not forced to use Spring annotations in their Hibernate DAO/Repository classes.

The converse is also true. Developers can write code that will accept the call from a JMS container without using any JMS code at all. Spring supports sending messages to a plain-old Java object, even converting the incoming message payload to a Java bean using the Spring converter framework. This promotes writing business-level abstractions and allows Spring to convert enterprise messaging APIs to normal business calls so that developers aren't working in the weeds just to send and receive asynchronous messages.

Finally, Spring supports using standard Java EE annotations, such as @PostConstruct, @PreDestroy, @Resource and others. If you need a Java EE API, by all means use it. Only wrap infrastructure with APIs where you will gain a benefit.

Wrap-up

I feel Java EE has made great strides from its beginnings as a Java brother to CORBA and EJB 0.9/1.0. The Java language has improved vastly from the 1990s and has accelerated innovation since Oracle purchased Sun. This is a Good Thing. However, another Good Thing is not attempting to kill off the very ecosystem that Java EE has helped to foster.

If Java EE didn't have to compete with Spring, would it have improved as much as it has? If Java EE didn't have Hibernate as a competitor in the database API space, would it have created JPA? If Java didn't have Ruby, Groovy, Clojure and others to compete with, would it be pondering closures and resource cleanup code?

In short, innovation comes from many places and spurs others to act. We may find SpringSource reacting to changes in Java EE, and that's fine. What isn't fine is to suggest we don't need "third-party" APIs anymore because Java EE has matured.