Spring 3.0 is one of the major things that we are talking about at our SpringOne 2GX conference and it really continues the work of 2.5 and indeed earlier releases of Spring in trying to reduce the complexity of applications built with the framework. Fundamentally the role of the framework is to absorb complexity. The role of the framework is to take the complexity that otherwise would complicate your business logic and move that infrastructural complexity inside the framework and make your life as a developer simpler. So one of the things we are really proud of is each release of the Spring Framework has added capabilities in the framework that make application code written to the framework simpler. So for example if you build an application with Spring 3.0 there will be fewer lines of code and configuration in that application than if you built it with 2.5 and the benefits were similar between 2 and 2.5 etc.
So the new features - probably the biggest simplification feature is the introduction of the new Spring Expression Language. The expression language is available in all types of configurations, so it is available in annotations and it's available in XML bean definitions. It means that for example writing a configuration that references environment variables or perhaps properties of other Spring managed beans becomes very concise; indeed trivial. This is a particular benefit to annotation driven injection so now it is possible to inject values with an @Value annotation where the value is resolved by an expression.
This means that it is now easy to for example get things like system properties or web application values without the need to recompile your code when something changes. So that will definitely reduce the size of Spring applications. It means that it essentially increases the power of the annotation driven injection model, so it means that there are more things that you can do without any need for an XML bean definition. Another area of improvement is the Spring MVC framework, so we have introduced the PathVariable annotation and this goes hand in hand with the REST support that is introduced in Spring 3.0, so it becomes very easy to expose, as a natural extension of the Spring MVC model, RESTful interfaces to an application.
Another feature that I am pretty excited about is the addition of the @Configuration model.
So this is Spring Java configuration; it is essentially an internal DSL that uses Java code which is annotated to define Spring beans. This has a number of interesting characteristics as an addition to the Spring developer's arsenal. What it means is that you can write arbitrary Java code to create Spring beans. It also allows inheritance of configurations. So for example you can write a superclass that is abstract and forces someone creating that application context to define particular bean definitions. It is also type-safe and very re-factoring friendly. So, there are certainly classes of configurations, types of configuration requirements, where it is very valuable to be able to use Java code. You might think, "Well, if I am creating my objects using Java code, why am I using Spring?"
Fundamentally what Spring's @Configuration model does is give you Java object creation on steroids. So it means that your @Configuration classes benefit from Spring injection. They also benefit from the fact that all beans that are defined in Java configuration benefit from services like AOP Weaving; so for example transactional security services, you get all the good things that the Spring container can do for you but you also get the ability to define objects in arbitrary Java code. So it's kind of like having your cake and eating it: if there is a situation where you really want to use new and you really want to call arbitrary Java code you can now do that but have the full power of Spring behind that.
Another interesting simplification feature of Spring 3.0 is the introduction of meta-annotations. Meta-annotations don't actually sound like a simplification feature but, trust me, they are. What this means is that you can actually annotate your own custom annotations with other annotations that are meaningful to Spring. So for example you could define a particular component type - so creating the annotation @CustomComponent - and the custom component type perhaps should be transactional, should have certain security characteristics, maybe it's a Spring @Service; and you can annotate it, annotate your custom annotation with those Spring specific annotations.
This has two benefits: firstly it can make your application code more concise because now you have a single annotation, and secondly it reduces dependence on the framework because now you are annotating your types with your own annotation not with a Spring annotation. Another benefit, which of course is very important in programming overall, is it makes the intent very clear; so you can define your custom annotations and then it makes it very clear when you annotate a type with that custom annotation what the role of that type is in your application. So essentially it's what UML would call stereotypes.
I think of it more as a form of inheritance for annotations. So in Java, annotations cannot participate in inheritance hierarchies, which can be kind of annoying when you have different annotations that you want to have common property names on. However you can actually create an easer relationship between annotations in a framework such as Spring by actually looking at annotations that are annotating your annotation and respecting the processing rules that they would imply. So I really see it like that. I mean another way of looking at it is, say my @CustomComponent annotation is annotated with @Service, @Transactional and @Secure, so essentially it's like implementing three interfaces. So it's abstract inheritance amongst annotations in the way that we can process it in the framework.
Actually they are really quite different. I think if you look at the annotation driven injection that we introduced in Spring 2.5 some of that functionality actually was inspired by Guice. So if you look for example at the way we can do qualifier annotations, that really is the same notion of annotation binding that Guice introduced. What Spring's @Configuration mechanism is is actually quite different. Firstly it actually has a completely independent history from Guice - I mean the first prototype I wrote back in 2005, way before Guice - but there is a fundamental difference between @Configuration and Guice, or Spring's @Autowired annotation style, or indeed any other annotation driven configuration option.
The difference is that in Spring @Configuration you annotate the class that is creating Spring bean components. In Guice, as with Spring's @Autowired or Java EE's @Resource, you annotate the classes that are being configured, and this is a fundamental and important difference. So when you create an @Configuration class what you are doing is creating a class that contains recipes for creating Spring managed objects. So an @Configuration class will contain a number of @Bean annotated methods. Each method that is annotated with @Bean is a recipe for creating a Spring bean.
Depending on the scope of that it may be invoked many times or it may be invoked just once and the return value essentially cached by the container for the lifecycle of that Spring container. So it's a very different approach in that it uses annotations to create an internal DSL for configuration, rather than annotating types that would be managed by Spring. This is quite interesting in that it allows you to, if you wish, not annotate the classes that are being Spring managed. So it works really well for classes that you can't, or don't want to, annotate. If there's any similarity with Guice with @Configurations it's probably more in Guice modules, certainly not in Guice use of annotations.
4. What's the migration path for existing Spring 2.0 and 2.5 users to Spring 3.0?
Well of course one migration path is "do nothing"; so we believe that Spring Framework 3.0 is as near to 100% backward compatible for regular application developers as you can get. And that is something that we have, I think, a great track record of with respect to Spring. The first thing is that you don't need to go change anything just to work with Spring Framework 3.0. There are some classes that are pruned so for example things like Apache Common[s] Attributes support, but essentially those are things that no one is using, at this point.
So you really should be able to take your application, upgrade your version of Spring and have it work just as it works now. However there are certainly things you will probably want to take advantage of. So the expression language is a really nice potential replacement for things like PropertyPlaceholderConfigurer. Certainly if you've got configurations where you've got one bean being configured by referring to a property of another bean, that is going to become much simpler with the expression language. Certainly if you are exposing any RESTful endpoints you will find that using the new @PathVariable is probably going to be a great deal simpler than whatever you were doing before. You'll find that if you are writing MVC applications some of the new bindings, like @HeaderValue that you can use in your method signatures, will make it easier to decouple yourself from the servlet API and that in turn makes your web controllers easier to test, so there is a clear benefit there.
With respect to the @Configuration option, if you want to try that, you can mix and match with your existing configuration. So @Configuration classes themselves are dependency injected using Spring and you can simply start dropping in some @Configuration classes if you want to try that means of configuration. And Spring processes all the contributions from different forms of configuration.
So really it's a pretty easy migration path. We recommend that the community upgrade, but upgrading really should start off as simply as replacing your JAR files and then gradually as you need to touch your code you can take advantage of new and improved features.
5. What are the plans for Spring 3.0 compatibility across the Spring portfolio?
Typically when we do a major release of the Spring Framework there is an impact on other projects because obviously they want to take advantage of the new functionality. I think the biggest thing in Spring Framework 3.0 from the point of view of other projects is the expression language. Because if you look for example at Spring Batch, if you look at Spring Web Flow, if you look at Spring Security, if you look at Spring Integration, there are many very natural applications for the Spring Expression Language. So you'll certainly be seeing a wave of releases - some of these projects already have milestones out - that will synchronize around Spring Framework 3.0, and the biggest thing probably from the point of view of many of those projects is going to be the expression language support, and that in turn will help their usage to be simplified.
Well I think it's a interesting example of the fact that the relationship is not just one way traffic. So Spring.NET obviously started as a C# reimplementation of Spring for the .NET community. I would not say "a port" because it wasn't like taking Java code and translating it into C#. What it was doing was writing from the ground up idiomatic C# that followed the feature set of Spring Java for the most part. So certainly the evolution of Spring.NET to a large extent has tracked the evolution of Spring Framework core however there are some areas where the traffic has been the other way and I think the Spring Expression Language is an example of how the Spring Java community benefited from the existence of Spring.NET. So the Spring.NET project has had expression language support for probably two or three years now, which is kind of embarrassing I guess from the point of view of Spring Java. But that experience was really helpful.
Actually another interesting example of how the Spring.NET project was directly beneficial to Spring's Java framework was with respect to the XML Schema support that we introduced in Spring 2.0; so the custom extensible XML tags. That's obviously a massive feature of Spring today. If you look for example at the demo of Spring integration and Flex integration that Mark Fisher and Jeremy Grelle gave last night, that was made so much simpler by those custom namespaces. That is a feature that was actually substantially driven by Spring.NET. I remember when we were discussing that on the mailing lists, it was interesting to see that, certainly at that time, the .NET community were far more sophisticated around XML Schema than the Java community and so there was really fantastic high quality discussion on the Spring.NET mailing list. And that had a really interesting impact on the design choices that we were able to make in Spring Java.
The first motivation for creating the tc Server product was that Tomcat is great. If you look at the Tomcat server that comes from the Apache distribution project, which SpringSource employees make a massive contribution to but is of course an Apache community project, it's a great product: it's extremely robust; it performs extremely well; it now is by far the most widely deployed enterprise Java server out there. So firstly we think Tomcat is great however there are a couple of areas where we think Tomcat is lacking. One of those is around deployment in the enterprise data center. So it's an extremely robust server, it performs really well, however it essentially has no management and monitoring capabilities.
And this is very important because now we are talking all the time to customers who want to migrate from, say, WebLogic or WebSphere or JBoss to Tomcat, because Tomcat is lean and mean, the combination of Tomcat and Spring gets the job done a lot faster than anything else. But one thing that they do miss, particularly if they come from WebLogic or WebSphere, is the level of peace of mind that they have for deploying applications across their data center. So, if you are going to be for example managing five, twenty, maybe two hundred Tomcat servers; if you are doing that with the regular distribution of Tomcat from the ASF, there is essentially no support out of the box.
So if you want to roll out to your two hundred servers a new application, if you want to monitor whether or not that was successful, if you want to monitor the health of those servers and that application going forward, there's really nothing there unless you build it yourself - and many companies build it themselves, they put resources into it and they find that the result isn't that great. So what we were able to do with tc Server initially was focus on that enterprise data center requirement, and we did that by building on top of our Hyperic management technology. And so it simply makes Tomcat easier to manage and safer and more efficient to operate in an enterprise data center.
We have recently announced a new facet of our tc Server enhancements to Tomcat and that is targeted not at operations but at developers. So the tc Server Developer Edition, which we just announced at SpringOne 2GX, enhances Tomcat from the development perspective. Tomcat is actually great from a development perspective anyway because it is really fast. What we do is add really sophisticated diagnostic capabilities that aren't in Tomcat and essentially aren't in any existing server. So this is really layering onto Tomcat something that is very beneficial to a developer audience but is clearly way outside the remit of the Apache community behind Tomcat. So we allow you to get detailed insight into the performance characteristics of your application during development.
You can for example drill down and see if you have performance issues, what layer of the application they are at, it even can show you exactly what SQL is being executed - because it's likely that SQL is being executed by something like Hibernate or OpenJPA or EclipseLink that you are not directly in control of - and it is very tightly integrated with the SpringSource Tool Suite. So the aim is that it enables developers to get more out of their use of Tomcat, and it enables developers to very easily write applications that are going to have good performance characteristics. It's important to note that both these variants of tc Server truly are Tomcat. We do not fork Tomcat. All the code that we write that is part of Tomcat itself is committed in the open to the ASF, and that also means that you are not locked in. So, if you look at deployment units, tc Server is 100% compatible with the version of Tomcat whose numbering it follows. So it's an enhancement - I guess to use object oriented programming terminology it's essentially the Decorater pattern applied to Tomcat.
8. What effect will have upon Spring development? What sorts of integrations can we expect to see?
In the Spring open source community there really won't be much effect at all. If you look at the Spring open source projects they are really driven by the community - obviously the vast majority of the code contributions come from SpringSource employees, but these are community projects and they aim to reflect and satisfy the needs of the community. So, if you look at the road maps of the Spring open source projects, they are not really affected by whoever owns the shares of SpringSource. Having said that there will be an impact in terms of increased resourcing.
It's great now that we are part of a much larger company, we are part of a company that is extremely profitable, we are part of a company that really is embracing and recognizing the importance of developer communities and the open source community, and there is going to be a positive effect. I think that we have seen, since SpringSource first raised money in mid 2007 and in turn built quite a large business on that, we have seen our ability to contribute to open source increase, and I think we'll see that increase further within VMware. So I think the folk in the open source community should sleep very easily because there will essentially be no change that is not positive for them out of this and the change really will purely amount to resourcing rather than road map changes.
Certainly if you look at what technical synergy exists, there is a real technical synergy and it's around the server and middleware experience as a whole rather than the individual open source components. So if you combine VMware's assets in, for example, internal cloud technologies with the vSphere platform; if you combine that with our servers and frameworks and of course the SpringSource Tool Suite IDE, you end up with the ability to deliver a high quality internal enterprise Java cloud. And that's one of the major areas of focus. If you look at the public cloud similarly will be able to build with Cloud Foundry technology and the VMware vCloud initiative.
Another area of technology synergy is around our Hyperic management technologies and vSphere and vCenter.
So Hyperic actually really compliments the capabilities of vSphere very nicely, because vSphere needs to make decisions based on the performance characteristics of workloads it is running. It does a pretty good job of that by looking at things like CPU usage, memory usage and IO but Hyperic essentially can give it eyes and ears throughout the application stack through its ability to instrument a very wide range of applications. So, we see a very natural complementary relationship between those technologies as well.
One of the great things about the overall combination of SpringSource and VMware, which is one of the reasons that I thought the deal was a good deal, is that there is no product overlap. So for example you look at Sun going into Oracle, if and when Sun ever actually does go into Oracle, and now you've got WebLogic Server, you've got GlassFish and you have to wonder "Well what exactly does that mean?" I mean Oracle made it very clear when they killed their own application server after they got WebLogic that they want to have one application server. So we're, I think, very fortunate in that none of that kind of tension exists. And I think that is very positive and it also means of course that the incremental value to VMware in terms of the strategic conversations it can have with its customers is pretty significant, because now they can talk to their customers about middleware, they can talk to their customers about developer productivity, as well as the things that VMware traditionally has talked to their customers about.
9. What can we expect to see from SpringSource over the next year or two?
Well I think there really are quite a number of initiatives at SpringSource so I would say from the community side you will see more of the same, and I think more of the same is a pretty good thing. This of course will span the open source projects, but it also spans other technologies that are available to developers and are also free. So for example the SpringSource Tool Suite, is a product that's made immense strides over the last few months. Firstly SpringSource Tool Suite is now free so anyone in the Spring community who wants to pick it up can go download it, do whatever they want with it; there is no requirement for them to pay us anything. And SpringSource Tool Suite really can make Spring and Grails development significantly easier.
So for example if you want to get started with Spring, actually the first download that you make really should be the SpringSource Tool Suite. Not only will you get the best Spring tooling available but you also get the different Spring open source projects included in that download. So for example if you want to use Spring Roo, if you want to use Spring Integration, it's just there and you can go. One of the most recent things that we have done in SpringSource Tool Suite is started to add support for Groovy and Grails. We have made very significant improvements to Eclipse's Groovy support and we have also added Grails wizards and other functionality to the IDE.
This is still in beta but over the next few months I think you will see really top quality tooling for the first time in the Eclipse ecosystem around Grails and Groovy. So SpringSource Tool Suite I think is definitely something to watch. And with the tc Server Developer Edition: that comes out of the box with SpringSource Tool Suite, so it gives you everything you need to be a productive developer in one easy package.
Some of the other things that we are excited about from the Spring perspective include as we mentioned revving various of the open source projects to take full advantage of Spring 3.0.
In terms of our commercial products you will see a lot of emphasis on both the Hyperic management product and the tc Server product, and we are working very hard to enhance those products. Interestingly one of the things that we are engaged with presently on Hyperic is modernizing the architecture. Hyperic is an application that was originally architected a number of years ago and it's kind of a measure of its success that it did what people wanted so it didn't need to be re-architected but this is basically an old school application: the thing still runs on JBoss; it still has EJBs in it. Obviously all the entity beans are long gone but there's still a layer of session beans in there.
And it has exactly the same problems that you would expect: the server JBoss takes a lot of time to start up; EJBs totally suck for testability - we know this stuff. So we are currently engaged in re-architecting it to take advantage of Spring and be able to run on Tomcat, or potentially dm Server, in the future, and the results that we are initially seeing are that we are going to be able to make that product significantly faster and we are also going to be able to be far more agile in how we take that product forward. We are seeing a lot of customer interest in Hyperic so that is definitely a major investment that we are making and really trying to take that product to achieve its maximum potential.