Research released this week by Evans Data showed that 73 percent of the market currently use or plan to adopt the Spring application framework for Java within the next two years. More remarkable is that 83 percent of companies with 500 or more developers use Spring, according to the study[/url]. So I thought it would be a good time to speak with Rod Johnson, CEO and founder of SpringSource, and author of the open source framework that some in the Java community view as a superior alternative to EJB.
Rod Johnson: The Evans report [shows] the percentage of people motivated by productivity. Growth in use of Spring has been steady over time. It was first launched as open-source in Feb., 2003, and has now surpassed 5 million downloads. You always wonder...sure, people are downloading it but are people using it in production? That usage is also extremely high.
Requirements for Spring skills are surpassing those for EJB skills, verified by checking search engines and job sites. We also use Indeed.com, which has a job-trends tracker across online job search engines and covers large sample space. Trends have been extremely clear that Spring job requirements are growing very rapidly. And large numbers of people looking for this skill set means they are doing things with [Spring] in production, not just evaluating it. So we’re well aware that as fast as downloads are it’s followed by extensive use in production.

(Note: A job trend report for EJB during the same period showed a relatively flat trend line. EddieC)
The main advantage of using Spring is productivity. People find that they can develop apps faster and they can maintain them more easily once they get into production. 83 percent of application development activities is around maintenance. And developers switching [from] EJB in favor of Spring have said they got an increase in productivity.
Another reason is that Spring tends to make apps more portable. In the traditional Java EE environment, code requires an in-house framework and is intimately linked with the app server. There are a number of problems with that. Testability issues are significant. Also, what happens when there's a revision with the underlying app server? Will that change impact your code? What if I want to get rid of WebSphere and run on Tomcat? You couldn’t do that if you’re linked with a Java EE server.
Because Spring provides a replacement for the EJB container that is more portable. [With Spring,] you can run your business logic in a Web container, a full server or as an app that doesn’t have any container. App servers divide apps into two levels. In the top level it manages your business objects, [and controls] how they get configured and services at runtime. Second is the deployment model, [which provides] enterprise services like messaging and transactionality. Fundamentally, app servers do a good job on the first part, but not on the second.
There's not really anything else like Spring. If you look at the app framework space, there are other projects that attempt to cover the same ground but none of them have. SpringSource also has the dm Server [OSGi -based]app server, and are the leading provider of support services for Tomcat. We're also the largest contributor to the Apache Tomcat project.
There's been significant growth in dynamic languages. We work in static Java. With the acquisition, we add Grails, a JVM interpretation of the same kind of key drivers you see behind Ruby on Rails. Ruby on Rails is simple for simple problems. But when you get into more complex problems you run into a wall. We think Grails is superior for people who want a dynamic language.
For example, imagine you’re an organization that's thinking of moving your Web app to a dynamic language or writing a new one. You’ve heard of their productivity benefits and you want to check that out. You can choose between Rails and Grails. If you use Rails, you don’t have access to any infrastructure (management tools, etc.) you had in the Java world [and] you don’t have access to existing code written in Java. If you use Grails, you keep your infrastructure and you don’t have to throw away things that are really good. With Grails you get the productivity benefits of working in a dynamic language and you don’t have to throw away everything you've invested in. With Grails, if you get to a hard problem, you can jump into Spring.
Grails uses Groovy, which is much more like Java, but maps to Java classes in a way that other such languages do not. Grails is built on Spring [which sits] on top of the runtime stack. When you have a Spring app running, Spring has taken on responsibilities of the app server for managing the business logic, etc. In the case of Grails, you’ve got another layer on top those capabilities, and every component Grails generates is a Spring-managed object. That's important from a support perspective [because] at runtime, Grails is leveraging highly mature technology from Spring rather than inventing its own component model. If you’re a grails developer and need to access advanced functionality you can’t access directly in Groovy, you can configure any of the Spring managed objects and you have its full power at your disposal.