Rod Johnson About Spring Framework 3.0 & Others

1. My name is Srini Penchikala, I am here with Rod Johnson from SpringSource. Rod, let me start with the upcoming release of Spring version 3.0. It supports a RESTful web service development. What does this new support for REST web services mean to the existing Spring Web Services product, which is based on SOAP framework?

This is something that we say is really being quite complementary. REST has been clearly growing pretty dramatically in popularity in the Java community, in terms of features that are requested by user, REST is almost certainly the number 1 right now. We don't say it is reflecting the move away from the Spring Web Services project - it has a very particular purpose in life, which is contract-first WSDL oriented web services and that remains a valid kind of web service usage.

In fact, in terms of the contributions to the REST supporting Spring framework 3.0., Arjen Poutsma who was the creator and lead of Spring Web Services project has actually done most of the work on Spring 3.0 REST implementation as well. We view those 2 projects as complementary and we are ensuring that we keep them in line. In fact, in Spring 3.0, we are moving to Spring framework Core, some of the OXM (Object- to XML Mapping) functionality from the Spring Web Services project.

2. That's good news for developers, because in one of my previous projects I have used Spring Web Services JAR files to be able to use the OXM APIs as part of the Spring core. Spring 2.5 had support for Domain Driven DI, with @Configurable annotation as well as @Service and @Repository annotations, which were 1-to-1 mapped with the DDD elements from Eric Evans' book. Are there any upcoming features of support for Domain-Driven Design in terms of other AS?

There is nothing new specifically around that in 3.0. Frankly, I think that @Configurable is a really hidden gem in terms of Spring. I've recently been writing a Spring application, if you like, in the same way that an NG would using Spring framework, Spring Web Flow and Spring Security and I've been using @Configurable heavily. I think it works up certainly brilliantly. I think our focus with 3.0 will be communicating the support that is already there.

The problem is not that there isn't enough functionality, the problem is that the community doesn't seem to be aware of it. Of course, @Configurable, allows you to dependency inject any POJO at all, using Spring, regardless of how it's instantiated. It doesn't need to be instantiated by Spring. You could instantiate it using new (keyword), you could have it instantiated by OR mapping tool or any other framework and it can get the benefits of Spring dependency injection.

3. Let me move on to the recent addition of G2One to SpringSource group - what other features the developers can expect to see in the future release of Spring in terms of Scripting languages, especially DSLs with this recent acquisition?

I think Groovy is an excellent language to author DSLs in. Indeed, we added in Spring framework 2.0 the ability to define any Spring managed object in a variety of languages, other than Java, and one of these languages was Groovy. In fact, at that time, Guillaume Laforge and I presented it to a conference in the US and he actually had quite a lot of input and I think he even made some code contributions to improving that support, specifically for Groovy DSLs. Now, of course, Guillaume is part of the SpringSource and he is already getting involved in some internal discussions and I hope that he'll really be able to help to maximize the potential of authoring DSLs and getting maximum benefit out of Spring management for those objects.

4. Regarding the maintenance release licenses. Can you discuss a little more about that and what it means? What was the rationale behind that new model and what it means to the developers?

There is no change to Spring's license, so Spring framework is Apache license software and it remains. What we announced is that maintenance releases of old versions of Spring, we are only going to provide to our customers. If you are not a SpringSource customer, you will probably be able to obtain the source code and build, for example, a Spring 2.0 JAR, or after Spring 3.0 comes out, a Spring 2.5 JAR. You build that for yourself, but there is no kind of regular package release to the community. We think that's a very fair balance in the open source communities, fundamentally about innovation, about getting the latest and greatest features.

For example, if you are a user who has just upgraded the Spring 2.5.6, in 6 months time, Spring framework 3.0 is final and you found a bug that is causing you a problem in your 2.5.6. What we encouraged the open source community to do is upgrade to the latest version of Spring, and you'll be able to do that at no cost, you'll be able to do that with JARs that you can get in the community. If, on the other hand, you happen to be a large organization that cannot upgrade because they have conservative policies on such things, we think it would be perfectly reasonable, that if they want that old version of Spring maintained for them, they should be a SpringSource subscriber.

Basically, what we are trying to do is to ensure that the increasing amount of development effort that we have to devote to maintaining old versions of Spring doesn't negatively affect the ability we have to contribute to code that we are putting in the community. As you can imagine, the number of Spring versions that are being used in production is increasing all the time. It simply isn't reasonable to expect us to divert resources that could have put out free software for the open source community to maintaining for example Spring version 2.0 for large customers who just refuse to upgrade to the latest version.

The good news is, of course, for those customers there is a lot of benefit in the new policy, because we are clearly stating that the subscription customers will have enterprise grade support for up to 3 years on any version of Spring. In fact, in terms of the open source community, I think if anything it has a slight neat positive effect. In terms of the enterprise customers, it has a definite positive effect because they know where they stand, they can plan the immigration from any particular version of Spring without being afraid that they will go out of support.

5. One of the cool features of Spring framework has been dependency injection in a traditional sense. DI is the all about managing the dependencies between classes and now, with the SpringSource DM server, it is going to be managing the dependencies at a module level and also we have the Service Component Architecture (SCA) which is about managing the bindings and dependencies at the component level. Spring already has support for DI as well as OSGi via SpringSource DM server. Can you talk a little bit about the Service Component Architecture and if any support from Spring is coming up in that area?

SCA is a specification that came out of consortium at which we were actually one of the founding members. We think that in terms of assembly module for SOA, SCA may have value. In terms of the injection space, I think the assembly in the small - Spring clearly provides a solution that is portable between all those kinds of technologies. For example, if you author a POJO, you can inject it with Spring and even the Spring configuration you have will be equally applicable in the OSGi world, in the Java EE world or potentially in any SCA world. We don't see any opposition between what Spring does for injection and what SCA does.

In terms of the dependency management of the SCA you could argue there is more of a conflict between SCA and OSGi because Spring is not really in that business. Spring is in the business of providing a really good component model and enterprise services. SCA has a component model that is very weak. It also has Spring bindings where you can use the Spring component model with the SCA according to the SCA specifications. SCA is not so much in the business of fine-grained component model as in the assembly business of different modules. There, I think, certainly is a bit of overlap between the SCA and OSGi. Will SCA be a technology that SpringSource ever chooses to support in their products? It's possible; it really depends on the amount of traction that the SCA gets in a user and customer community. Certainly, at the moment we say OSGi is something that has much more traction.

6. In the past, what seemed to be the core of SpringSource's model or SpringSource's product line was Spring framework itself. Now, with the focus on SpringSource DM server, it seems that SpringSource is moving into the application server business. Which of these do you believe is more important or more strategic to the future of SpringSource?

That's a very good question. Fundamentally I think it's been proven from the entire history of both Spring and SpringSource that we've been gradually broadening what we do. For example, you look at what Spring framework version 1.0 did, look what version 2.0 did, what 2.5 did, look at Spring Security, Spring Web Services, Spring IDE, our involvement in the AspectJ, etc. We've been broadening all the time. Our goal is quite simply to be the leading provider of enterprise Java software. So the answer to your question is fundamentally all of the above.

For example, SpringSource is by quite a wide margin the leading contributor to the Apache Tomcat project, we're also the leading provider of support for Tomcat. We lead the AspectJ project and we say our vision is to provide the strongest set of innovative enterprise Java technologies to our users and customers.

7. The upcoming release of Java Enterprise Edition (Java EE 6) has some features that look very much Spring-like. For example Java EE profiles with a servlet container support and as well as packaging EJBs in WAR files which Spring has been supporting from day 1. Can you share your thoughts on this convergence between Java EE 6 and Spring in terms of features?

Obviously, we think it's a good thing because we think our features are good features and many thousands of developers agree with us. It shows a positive change in the Java EE 6 technology set. Their convergence may be such that we choose in DM server, in a future release, to implement the Java EE 6 web profile. We do not have any interest in implementing the full profile. I think our community would quite rightly think that we are insane if we were implementing entity beans version 1.1 and 2.1 in a DM server. In terms of what is in the web profile, it's not final now, but from what we've seen it is something that we could implement without too much difficulty and if it was something that we thought added value to our community, we would do that and we would look to certify SpringSource DM server.

8. Speaking of Java EE 6 and the Spring 3.0 time lines, Spring 3.0 will be out before Java EE 6 is scheduled to be released. Can you talk about how Java EE 6 features will be supported in Spring when Spring 3.0 is out and after that?

It's hard to predict because firstly we don't know exactly what will be in it and secondly we don't know when Java EE 6 will be public. The role of Spring framework will merely be a Java EE 6 implementation because Spring is an application framework and component model, not an application platform in itself, so where we will look to track Java EE 6 at a platform level would be the DM server. Of course, the functionality that is needed will be going in various open source projects, so I would expect that there would be some functionality that would go in Spring.

We previously had a project called Pitchfork that was an EJB 3 implementation based on Spring. There will probably be a new project, which will start from scratch on a Spring 3.0 basis and do the same thing for EJB 3.1, then there are the technologies that may or may not be in such as WebBeans, which might be there in Spring projects to implement. With respect to timeline, I don't see it being predicated on Spring framework 3.0. I think there will probably be a number of open source projects that will track different parts of the specification and the whole thing will be rolled into the DM server and we will certify DM server as a Java EE 6 compliant server.

9. Now we know the features that Spring 3.0 will support when it's out. What can Spring developers expect in the future releases - 3.0 and beyond, in terms of features and upcoming releases?

I think one of the most exciting features, from my point of view, is the Spring Java Configuration - a project that is going to be merged into Spring framework core. It's likely that in Spring framework 3.0, a kind of minimum feature set of that will make it into the Spring Core, but there will be quite a lot more where gradually those features will mature and make their way into core. That provides another quite unique and very interesting way to author Spring configurations in a kind of DSL form. I would expect to see definitely further integration between Spring and Groovy, providing the option for people to use Groovy more and more effectively with Spring.

In Spring framework 3.0 there will be a number of deprecations, for example, the old MVC controller hierarchy. We view the Annotation based Spring MVC usage model that we introduced in Spring 2.5 is being a far superior replacement. That will be deprecated in Spring framework 3.0 and in the next version, whether it's 3.1 or 4.0, those classes will be removed. We don't approach deprecation the way some seem to approach deprecation, which is "Let's put a message into it" that will take years when they compile a code. Our view on deprecation is that it is a serious statement of intent. If we deprecate something we are saying "Hey, guys, it's time to think getting off this because we don't think it's a good usage model anymore." There will certainly be a bit of - if you like - Spring cleaning in the next release after Spring 3.0. Probably the most obvious part will be the Spring MVC controller hierarchy. Certainly, we'd be looking depending on the timelines of Java 7, we would be hoping that it would be possible to start working with Java 7 at that point.

10. In terms of tool support, Spring IDE and there have been Tasktop and Mylyn support for collaboration type of efforts. Are there any upcoming features that a Spring developer should know about the Spring IDE and other tools?

Spring IDE is something that we say is fairly mature and most of the new work that we are doing in tooling is around the SpringSource Tool Suite. This is subscription product, which is free for personal developer use. It bundles Mylyn and it bundles AJDT, Spring IDE and a whole bunch of other plug-ins and additional code that really helps with Spring development. Certainly, we are putting quite a lot of effort into that and there are new features, such as Quick Start, wizards and the whole range of things to make Spring development easier. In terms of open source tooling, one thing that the community may not be familiar with is the DM server tools project - that is open source tooling for DM server and that plugs right into your regular Eclipse distribution.

11. With the recent increase in the interest in cloud-based solutions, how do you see something like SpringSource DM Server participating in a cloud offering?

It is definitely something that we are looking at from a partnership point of view. We do anticipate that cloud computing is going to change the way in which many people choose to obtain the software. For example, we think that people aren’t necessarily going to download individual zip files for projects, but they are quite likely want to actually get an installation in the cloud that they can go and use both for development and production purposes. We are certainly looking at being able to provide that kind of benefit to both the customers and the open source community. Thus far, we don't have any features in DM server that are specifically targeted at cloud deployment. However, I'd like to say that DM server is ready for cloud and virtualization scenarios.

For start, it has a very small footprint - DM servers are modular servers - it literally only starts up those bundles that need a Runtime. The footprint compared to every J2E server out there is dramatically smaller in terms of memory usage. We see that and other qualities of DM server, as qualities that are very beneficial in a cloud deployment environment. We were also talking to a number of the vendors of both the virtualization and the cloud space and we are hoping to have some initiatives to announce very soon.

12. Another interesting product is the Spring Integration product that was announced late last year as the implementation of Enterprise Integration Patterns (EIP). Are there any new features coming up in that project? What's the road map for that going forward?

Spring Integration is about to go 1.0 final, so, essentially, it is currently growing its community in the next set of features it will be very much driven by the community using the project. We are pretty happy that, in terms of the initial vision, we've actually executed that vision. We've got a high quality implementation of a lot of the classic enterprise application integration patterns and it next brings the question of "How do you connect with the whole range of technologies?" I think that is something that we expect input from both the open source community and from SpringSource customers to really help drive.

13. Right now, Spring framework and all of the pieces of the Spring Portfolio tend to have a Java focus -well they do have a Java focus. There is also a Spring .NET project. Do you foresee in the future moving all the Spring portfolio or extending all the Spring portfolio into other languages, such as .NET or Groovy or possibly something like Ruby?

Whether we speak to other languages, there is a Spring Python project, which is now hosted in the Spring Extensions project, which is kind of an umbrella project for a lot of add-ons. That thing is going on quite well, I think it's version 0.9 right now. With the respect to Ruby we don't have any particular plans. Frankly, I'm much more interested in Grails than I'm interested in Ruby on Rails and I think that the main focus in Spring will remain the JVM. Fundamentally, we want to make developers on the JVM more successful and we don't believe that it actually makes sense for enterprise users to jump to something radically new, like a Ruby on Rails Runtime, which makes it difficult for them to reuse what they already have, doesn't provide the same performance and scalability benefits.

We think we'd much rather help to make the JVM extremely competitive in terms of productivity. That was one of the major reasons behind our acquisition of G2One. We think that Grails is actually taking a lot of the good things about Ruby on Rails, but it has made it possible for developers to enjoy those good things without throwing away a lot of investment, without throwing away the performance and other benefits that they can get on the JVM.

14. What about the .NET side?

Spring .NET is something that has a smaller community than Spring Java, but definitely we do see steadily growing interest in it. We'll certainly be taking the Spring .NET project forward. There is no major initiatives around that beyond - we continue to track the Java Spring framework and provide those core component model benefits to .NET developers.

15. What I am thinking is about other pieces of portfolio such as Spring Web Flow and Spring DM server and these other components which build on top of the Spring framework. Is there a plan to move those to something like .NET?

The DM server, I think, is not something that we translate to .NET because I've certainly expressed a lot of confidence in SpringSource's ability to compete in the enterprise Java platform space. I believe that we can do that, we've got incredibly deep expertise and also we are well aware of the problems with the existing vendors in the enterprise Java space - none of them has total power. If you look at .NET, any product desiring to compete with the .NET platform is dead on arrival. We can’t hope to provide something equivalent to DM server if it would be perceived to be in competition with the .NET platform - it just doesn't make sense. Something like Spring Web Flow would be very much needed to be driven by the customers or community.

Certainly, we have discussed the idea of Web Flow for .NET and I think there would be some benefits there. Interestingly, recently, Microsoft has actually started to introduce genuine MVC functionality for .NET and quite a lot of what they are doing is actually very good. After a number of years when there was no equivalent really of the front controller for the .NET platform, Microsoft finally seems to have come up with something that's pretty good. Whatever we did in the .NET space, would really be much more on the line of finding problems in the Microsoft stack and trying to make developers more successful rather than trying to promote our own platform, which wouldn't make sense.

16. For use cases like using workflow, the Spring Integration with asynchronous communication model and Spring Web Flow and Spring Batch, which provides the batch type of processing. Are there any upcoming features of Integration to make this three frameworks work together?

Definitely, I've had discussions with both Mark Fisher and Dave Syer, also Keith Donald. I don't think that there is anything that you say in the very near term, but there are actually a number of features in Spring Web Flow version 3.0, such as Java flow definitions, which may actually make it easier to provide a common or at least a very consistent model between, say, Batch and Web Flow.