Thoughts on the Spring Framework

One of my goals for the year was to learn more about the Spring Framework, a layered set of modules that intend to make enterprise Java development easier.

In September, I took a class on Spring. Last month, I put together a presentation to share what I learned with my colleagues.

The bootcamp
I attended the Core Spring bootcamp in New York City. If you’re looking to learn about Spring in a classroom environment, there is perhaps no better source than Interface21‘s consultants as they are the company behind the project.

The course materials were solid and the class revolved around a real-world application scenario. For each segment presented, corresponding before and after projects for the lab were available in a workspace used by the free, Eclipse-based Spring IDE that was distributed to the class.

A copy of Pro Spring was included with tuition, but I’ve found the newer Spring in Action, second edition a better read. The instructors also noted that the older Pro Spring book had information on AOP and transactions that weren’t up to speed with the latest 2.x versions of Spring.

As you would expect from a technology that in practice killed EJBs, the Spring bootcamp focuses on middle-tier applications. However, there was good coverage of Spring MVC, which I hope to a adopt for a new project built on WebSphere 6.1 and J2SE 5.0.

Like Baldwin home from Paris
Some time after the course I had the opportunity to present an overview of the Spring Framework to my department. The audience consisted of developers as well as project managers and other non-technical types, so the goal was to keep the presentation accessible as well as sufficiently informative.

To sum up the philosophy of Spring in a nutshell, I hit on three characteristics with real world parallels. I hope they went over well, and I think some of the other learning materials out there would benefit from a similar approach. It seems the ideas behind Spring could be conveyed easier than they often are (another reason I like Spring in Action).

  • Inversion of Control / Dependency Injection
    Give code what it needs, don’t make it ask
    Does your car buy its own gas? Should it have its own credit card? Or use yours?
  • Interchangeability through Interfaces
    Keep things “black box” enough that you can swap individual pieces out when you need to
    Your twenty year old lamp can take either a traditional incandescent light bulb or a new compact fluorescent light bulb which provides a 75% more efficient way to do the same thing in the same standard socket.
  • Aspect Oriented Programming
    Terrible name and difficult vocabulary for an easy-to-grasp concept
    Consolidate logging and access control code, don’t repeat it all over the place
    Imagine an assistant tracking your billable hours to several projects during the day for you while you focus on your real job.

Silly middle-tier guys, or, what’s with that goofy .htm extension?
I have one outstanding gripe about Spring. Spring MVC in particular. I let it slide in the class, but since the foolishness is repeated in other materials for learning Spring I felt I had to speak my mind.

In a lot of examples for configuration of the Spring MVC DispatcherServlet, folks will tell you that “.htm” is the preferred convention for the mapping requests to the front controller.

The argument goes that we should trick the search engines into thinking this is static HTML content and besides, the mapping reflects that even though the page is dynamic, it is indeed rendered in HTML. Furthermore, the “.do” convention from Struts is pure tomfoolery.

This is dogsqueeze.

I take exception with all those arguments. In fact, I’d go as far as to say the “.htm” extension for dynamic content is actually harmful:

  • Most developers deploy Java Web applications to an application server which is not also the front-end Web server. Application servers, such as WebSphere, are configured to serve only dynamic content, such as servlets and JSPs. The HTTP server, such as Apache, serves the static files such as HTML documents, stylesheets and images.

    What if you really did have a static file with a “.htm” extension deployed by one of your Web developers? Do you want to see her go bonkers when she can’t figure out why her file is not being found because you decided to map that extension to your servlet? WTF?

  • Do you really want to make the impression that you’re hosting your Fortune 500 or high volume e-commerce site on MS-DOS?
  • The “search-engine friendly” argument for the “.htm” extension goes out the window when you start using query string parameters anyway.
  • You’ve introduced goofiness at the cost of elegance, another tenet core to Spring. Sigh.

But honestly, if you’re going to go through with it anyway, just add the damn extra “l”, filename limitations (virtual as they may be) are a thing of the past.