NESS 2009: The Coming Spring

One of the sessions I attended at the recent New England Software Symposium is the one on new features in Spring 3. This covers Spring Core functionality. This session got my attention because the presenter was Craig Walls, who wrote Spring in Action. The main features he covered were:

• Spring Expression Language (SpEL)
• Spring MVC annotations (@PathVariable, @RequestHeader, @CookieValue, @RequestParam defaults), some to support REST.
• jsp tag to generate context-sensitive URL
• Declarative validation of some sort that may or may not make it
• Etag support
• HiddenHttpMethodFilter (more Spring MVC REST support)
• ContentNegotiatingViewResolver
• RestTemplate
• JavaConfig (Java-based alternative to XML wiring). This has been around for a while, but is being bundled in Spring 3. 
• Object-to-XML mapping from Spring-WS
• Java 5 support

This may seem a long list, but much of the work seems focused on Spring MVC. A session participant who did not use Spring MVC pointed this out during question time, complaining that SpringSource seems to spend much more effort reinventing the wheel and building an alternative API (Spring MVC) than providing real innovation to, say, a JSF developer. Even SpEL is basically a reinvention of Unified EL. (I later attended Craig's session on SpEL, but it seemed overkill to dedicate an entire session on another EL dialect.)

Craig, of course, is not a SpringSource representative and cannot speak for them. My personal opinion is that this is intentional. Spring is basically the alternative to the official J2EE/JEE stack. For many enterprise Java developers, particularly in agile-focused crowds like at this conference, it is the de facto standard. This sets up a collision, at least in terms of mind share, between the de facto standard and the de jure standard.

The way I see it (i.e., here's my strawman), the enterprise Java space has divided between the Spring Camp and the JSR Camp. Spring has a huge chunk of mind share among agile types and EJB refugees and is not really defined by any standards. The JSR Camp has J2EE true-believers regrouped, led by the likes of JBoss. You could do DI, declarative transactions and web tier with Spring, or you could use official standards like JSR-299, EJB 3 and JSF. One of Spring's main selling points is that you are not tied to an app server: your application is portable as long as it travels with the Spring container. But the catch is that your application is heavily dependent on the Spring container itself. The more dependent you are on Spring-specific APIs -- like Spring MVC or SpEL -- the more invested you are in the Spring platform. And that's good for SpringSource. The app server vendors will probably prefer you spend more time in JSR-land, since it's easier to use standards like JTA and JMS with a full J2EE app server.

I don't want to come off sounding cynical. The interests of the vendors aren't necessarily antagonistic to the needs of developers. For example, SpEL has potential beyond its current implementation: have you ever wished you could access a Spring bean in a JSP? I sure have.

The XML vs annotations debate

During the Spring 3 session, I had the opportunity to ask Craig Walls' opinion about the XML vs annotations issue. Spring seems to be moving from XML to annotation-based wiring, something that I have some misgivings about. With XML, you know exactly what each bean is getting injected with. On the other hand if you throw @Autowired all over the place the dependency injection becomes implicit, and often unclear. You could make the DI explicit by adding @Qualifier annotations, but then you'd be doing the very opposite of DI by moving dependency information into the dependent class. True, annotation is arguably not code, but at this level it is not a meaningful distinction. However you classify annotations, the fact is that you are adding dependency information to your dependent bean's source code, increasing coupling.

In response to my question, Craig did not take a hard position one way or another. But he did point out that with the right IDE tools, you can get the "big picture" even when wiring with annotations. It doesn't completely address my misgivings, but then I do understand the attractiveness of annotations in reducing metadata cruft. After all, I personally favor Hibernate's annotation-based mapping over its old XML metadata. But that is because ORM is such a leaky abstraction in general that I believe persistence information does belong in the code. With Spring, the whole point is to remove dependency information from the dependent code.

I wonder if we can pull back from the pure dicotomy of "centralized DI with XML" vs "dispersed DI without XML". There are 2 separate dimensions here: XML haters need not hate centralization of DI logic. In fact, why is XML essential to centralized DI at all? All Spring XML provides is a DSL (domain specific language) to express DI logic. And for that purpose, XML has limitations beyond readability. After all, SpEL is being introduced to add some expressiveness we take for granted in a programming language. What about other alternatives?

One possibility for centralized, non-XML DI is Spring JavaConfig, mentioned earlier. If you're going to wire up Java, why not use Java? On the other hand, Java itself is a relatively verbose language. Can we do better?

There is also Spring Bean Builder, used in Grails.  Check out the samples: it's very Java-like and much more concise than XML. Yes, it's Groovy, but in a DSL designed specifically for Spring. The fact that it's another language should not deter you, since Spring XML is a foreign language anyway. If it makes you feel better, you can put in semicolons. I won't tell. Plus, Groovy scripts are compiled at runtime, so you can make wiring changes without recompiling like you can with XML. Since SpringSource owns the Groovy people now, I wonder if there can be a bigger future for this component.