Interesting interview, especially on future plans. However, it would be nice to hear about Rod's thoughts on EJB 3. The spec takes on many of the IOC/Dependency Injection concepts facilitated by Spring and its "competitors", so surely closes the gap somewhat.So does Spring IOC still add enough value to justify substituting - or building on top of - the soon-to-be industry standard IOC, thus adding an extra layer of complexity and adding to a typical project's learning curve? For Spring and others to be taken on in light of EJB 3, they will need to be able to justify that the value-add is substantial.
Firstly, it's important to differentiate between a component model that adds some limited Dependency Injection features to help simplify its programming model (EJB3) with a true IoC container (Spring, Pico, HiveMind etc.). EJB3 does not standardize a general Dependency Injection mechanism. It's mainly a way of getting rid of verbose JNDI lookups (judging by section 8.1.3, "Injection and Lookup"). This is worthwhile, but it provides only a small part of the benefits that can flow from Dependency Injection overall.
provide a general IoC mechanism, with both Setter and Constructor Injection, Method Injection (in Spring 1.1), and the ability to manage object graphs of POJOs. It's possible to differentiate between "singleton" objects (shared instance, as with JNDI) or "non-singleton" objects (instance created on reference), supporting more advanced scenarios. Not to mention support for lists, maps (even nested), property type conversion etc... There's a lot more to a true IoC container than the EJB3 subset.
The Spring IoC container is also highly extensible, with the FactoryBean concept etc. It also integrates with AOP (Spring's own AOP framework and, as an additional option, AspectJ in Spring 1.1), whereas EJB3 does not provide an open AOP model...
In short: EJB3 may "narrow the gap," but in terms of programming model, the gap is still very wide. And Spring 1.1 (due out next month) and subsequent Spring releases should widen it...
Secondly, the Spring IoC container, like Pico and co, is usable in a wider range of scenarios than I would expect an EJB container ever will. (I have heard the aim expressed of making the EJB container "ubiquitous". Maybe it will happen, but I doubt it.) An IoC container distinct from the EJB container can be used anywhere
: not just in a J2EE context. (J2EE != Java.) For example, the Spring RCP (Rich Client project) is generating a lot of interest now, and we have some users using Spring IoC in applets and standalone non-J2EE Java applications. A consistent model across all those environments is valuable.
Thirdly, I think we have to be realistic about applying the word "soon" to EJB3. We're a long way from a Proposed Final Draft, let alone the completion of the JCP process and production-ready containers actually supporting EJB3. The market leader in the application server space is now WebSphere. WebSphere 6 will be released at the end of this year, and will support J2EE 1.4
, not 1.5. Thus it's reasonable to assume that WebSphere will support EJB3 in late 2005. Obviously people can't migrate to a new app server version overnight, so we'll see the user base come over in 2006. (And I doubt those guys are going to switch to another server to get EJB3 quicker.) It's clear from presentations I've seen at IBM user groups that IBM are focusing on today's technology set (quite reasonably). Thus EJB3 is just not an option now, and won't be for a while.
Fourth, Spring does a lot of things EJB3 does not seek to address. If I were programming EJB3 now (if I could
program it now), I would be likely to use Spring for true IoC capability, interception that can't be done with EJB, superior JDBC usability, client-side access to remote EJBs etc... So the two things are not mutually exclusive. A better EJB would be good, but it won't displace good J2EE frameworks.
So, I think the value add is very substantial.
RodJ2EE Without EJBSpring Framework