Power to the POJO – day one of the Spring Core Committer's workshop

If there is one wave (or hype if you like) flooding the Java/J2EE arena right now – well, there is JSF and EJB 3.0 and AJAX and Java 5 and …. – it is probably the Spring Framework, founded by J2EE veteran Rod Johnson. Spring seems to be everywhere. And doing anything, from O/R Wrapping to Remoting Services and from AOP container to Struts killer. Spring is being picked up by most of the large vendors, always a true sign for success. Or is it? Anyway, I have just concluded the first day of the First Worldwide Core Committer’s Spring Public Workshop, taught by Core Spring Committers Alef Arendsen en Rod Johnson (yes, the man himself), right here in The Netherlands. 13 lucky people attend the workshop, among my AMIS colleague Aino and myself.

We attend this workshop to of learn more about Spring, to assess the value Spring can add to our own J2EE projects, to understand how we can best position Spring for our customers etc. I also have to establish how I will translate a four day quite intensive workshop into a four hour Knowledge Center Session on the Spring Framework for AMIS colleagues, on June 30th.

Spring is not easy to define. It is a framework, it increases application serer independence, it allows for out-of-container testing – a major factor if wyou strive for test driven development and continuous integration – and most of all: it has you building applications using just POJOs (plain old java objects), programming against only interfaces. POJOs that are virtually unaware of their environment. They may have logical or functional dependencies on other objects, but they are free from configuration and implementation details. Spring is for one thing a powerful POJO factory; using configuration details that may be and probably are in an XML file, the Spring container produces objects on request and ensures that those objects are fully configured when handed over.

This first day, we focused on this bean-factory, the core Spring Container, and the concepts of Inversion of Control (or: The Hollywood Principce – do not call us, we will call you) and Dependency Injection. It all boils down to objects being configured outside your code and being instantiated by the Spring container based on those configuration details. Rod Johnson presented from just after 9 AM until about 5 PM when finally we got the change for hands-on. We have seen more in depth details about configuring the container, than I care to remember. These included registering Bean Factory Event Handlers, implementing your own BeanFactory, implementing and registering PropertyEditors, bundling many Spring configuration files, using parent bean definitions as base templates, using the JUnit Testing Framework for unit-testing and integration-testing using the Spring facilities for JUnit and much more.

Even more interesting… Lunch

Even more interesting perhaps were the lunch-discussions. All participants were quite senior java developers, often acting as technical architects and sometimes with additional commercial or project lead roles. And all are more or less in the same situation: too much is going on to keep track of it all, we need to select the most promising, value-added developments (tools, frameworks, architectural patterns etc.) and it is difficult to know enough about them all to make such decisions. Clearly JSF and EJB 3.0 are potentially big developments, but just how and when to apply them is not yet clear. One good thing about Spring is that it can be introduced in a very evolutionary way: you can start small – introduce just the JDBC templates for example -with no or few actual dependencies on Spring classes, and gradually increase the usage of Spring if the need or benefit arises.

Alef and Rod indicated that the major J2EE vendors – IBM, BEA and Oracle – are very supportive about Spring. Oracle’s recent donation of the Spring support for Toplink for example clearly demonstrates that Oracle is willing to commit resources to contribute to Spring and is probably anxious to be left out and miss the Spring boat altogether. Support for Toplink in Spring 1.2 ensures that Oracle is not left behind with some of the competition (Hibernate, JDO, iBatis) on board. SUN’s position is less clear: some people at SUN are clearly not happy about the Spring team’s position on EJB; it is clear that Spring is EJB-frustration-born framework. (“EJB is just a pretty bad component model on top of high quality services, just as clustering, transaction management, management, etc.”) Other SUN country organizations – especially in Western Europe it seems – have embraced Spring. And the JavaOne organization committee itself invited the Spring team to come and present. Johnson hinted that JavaOne may see some interesting announcement around Spring. These may for example suggest increased support for Spring from for example the three big vendors.

JBoss on the other hand seems somewhat under pressure. And of course if your core business is a full blown EJB container, and an open source framework that presents itself as an alternative to EJB – still providing access to high level J2EE services such as Transaction management and Remoting capabilities -, you have every reason so be a little nervous.

EJB 3.0

One of major challenges for Spring itself is the advent of EJB 3.0. With Spring Framework being – among other things – an alternative for EJB, because EJB (2.1) sucks, a new and generally seen as much enhanced rendition of EJB may undermine much of the motivation for Spring. Johnson et al. state that first of all EJB 3.0 is still far from being good enough. The persistence side – which is not really EJB at all – is probably a very good thing (POJO based and all). However the EJB remoting/distributing etc. part seems less likely to support. And of course Spring has become much more than just an EJB alternative. Spring could even make sense with EJB 3.0 wrapped under the covers of as a persistence service.

Furthermore, Johnson is not positive about the adoption of EJB 3.0, when finally released. The backwards compatibility with EJB 2.1 required from certified J2EE containers will probably mean that for EJB 3.0, we will probably still need the Enterprise Edition of an Application Server. There may be lightweight EJB 3.0-only containers that would then not be officially certified. Furthermore, large vendors such as IBM may need considerable time before an EJB 3.0 release of their Application Server can be available (2007 or even 2008 seem realistic) (although Oracle seem to be well under way with its OC4J preview of an EJB 3.0 implementation). Then of course there is the general speed of adoption of major new technology developments in large enterprises: it may be a while before for example Banks will be ready to adopt EJB 3.0.

Next editions of this workshop will take place in London – next week – and Atlanta. For both events there are currently 16 people lined up. See Spring Trainings.