Hi my name is Ryan Slobojan I am here with Rod Johnson at QCon. How are you doing?

Pretty good, I am enjoying the conference, I am enjoying being back in London.

Excellent, glad to hear it. So one of the first things that I wanted to ask you about is, there is an upcoming group of releases on March 20th related to the Spring portfolio, can you tell us a little bit more about that?

Yes, we've got quite a lot of new functionality coming across the Spring portfolio, and this includes, for example, the Spring Security version 2.0 release. This is the evolution of Acegi Security for Spring, so now it's being very clear that this is very much a core part of the Spring portfolio and it also really makes Acegi Security much easier to use. One of the problems with Acegi Security, historically, was that it was very powerful but it wasn't simple to use. And our motto with Spring has always been "simplicity and power" and I think we've finally gotten to the point now where we have greatly simplified configuration through using Spring 2 namespaces and made Spring Security a real pleasure to use. Some of the other releases that are upcoming include Spring Web Flow 2.0. There are a number of major enhancements in Spring Web Flow also geared around ease of use, and also additional functionality with respect to JSF and AJAX. So we want to make sure that, for users who are using JSF, Spring Web Flow is the most natural choice for them for a framework. We also have, actually, a variety of SpringSource product releases coming in the next month or two, including the SpringSource Tool Suite, which is a value-added distribution of Eclipse with many new features available to our subscription customers. Also the SpringSource Application Management Suite, which is a management and operational monitoring product that can provide detailed insight into Spring applications in production. And the SpringSource Advanced Pack for Oracle database which provides value-added connectivity to Oracle RAC, Oracle AQ and some other Oracle products.

Interesting. One of the things that you had mentioned was Oracle. Now one of the recent changes in the software development arena has been that Oracle has bought BEA and Sun has bought MySQL. How do you think that's changed the landscape for both open source and Java?

I think that's a very interesting question. I don't think that the Oracle acquisition of BEA makes so much difference for open source because obviously neither of those companies is an open source company. We have an excellent relationship with BEA and also a good relationship with Oracle so we actually think that it will continue to be a very good story around working with Spring and WebLogic, in particular, together. So with respect to open source, BEA, I guess, has used more open source than Oracle, so BEA for example has used Spring in the core of WebLogic 10. Oracle on the other hand is also increasing its use of open source so I'd expect it maybe to push that trend a little further within Oracle. I think there's some pretty significant implications for the JCP, because interestingly the app server market looks more and more like a two horse race now. So if you look at the conventional app server market it is now going to be totally dominated by IBM and Oracle, when Oracle acquires the WebLogic customer base. Meanwhile the challenge to BEA, in particular from JBoss, seems to have receded since Red Hat acquired JBoss. So, I think that is going to have some very interesting fallout. Essentially the full-blown Java EE server market is going to be largely a two horse race. And I think that may well encourage even more people to look towards lighter-weight solutions like Tomcat. With respect to the acquisition of MySQL by Sun, I think this is going to be a very good thing for Java. I think it is going to clearly help to drive Sun's commitment to open source, and I would expect to see, for example, and hope to see that the JCP should become more open, more like an open source process through this.

Excellent, and you had also mentioned that you believe there is going to be a move towards a lighter-weight solution such as Tomcat. Now do you think that the Java EE 6 specification, with its profiles idea, is going to help with that or is this something that is going to happen independent of that?

I think it is something that is going to happen in any case. I personally see Java EE 6 as being more a question of whether Java EE 6 is going to get with the program and ensure that Java EE remains relevant. I think we are long past the point where the Java EE specifications really shape the market. I think that there are a number of things in Java EE 6 that are very positive. One of them is profiles. I think it is very clear that people do value JCP standards, they value some a lot more than others, and I think it is very clear that users want to have standardized and coherent subsets. So I think that profiles is a very good idea, I also think the extensibility goal is a very good idea and recognizing that part of the role for Java EE is to create a level playing field on which innovation can flourish rather than necessarily delivering everything, from soup to nuts, that people need in enterprise Java. Of course SpringSource is involved in the Java EE 6 effort. I am on the Java EE 6 expert group and I do think in particular the profiles move is very good. Interestingly if you look at the statistics in terms of Tomcat take-up -- this is something I blogged about a couple of months ago -- I think Tomcat has gotten to a dominant position more or less without anyone noticing. There is no question now that on every set of numbers that I have seen, for share of different application servers, Tomcat is in first place. It is significantly ahead of WebSphere, which shows up in second place on most of those surveys. So I think it is very interesting that while Java EE has progressed in a particular direction, at least up until Java EE6, very large parts of the market have just voted with their feet and decided "Hey, this is the subset that we want".

And one of the other products which has come out recently is Spring Dynamic Modules 1.0. Do you see that as being a strategic component of the Spring portfolio?

Absolutely. Spring Dynamic Modules, we think, is an extremely important project because we believe that the combination of Spring and OSGi is the future of Java middleware. OSGi has definitely reached the point where it is going to help to reshape the server side in the same way that, for example, it enabled the highly successful Eclipse plugin architecture. However OSGi gives you an excellent dynamic modularization solution, solves problems like versioning, hot deployment, etc. It doesn't give you a component model, it doesn't give you enterprise services, it doesn't really give you the kind of experience that enterprise developers want. You put OSGi together with the Spring component model in enterprise services and then you get something that really is both very easy to use and extremely capable. So we see Spring Dynamic Modules as something that is very important to our strategy for that reason.

I have one question . In the last years we have seen a lot of drawback from enterprise technologies, POJO is more popular than EJB probably. Now there are profiles for J2EE 6, so I wonder what is your estimation about the future. Would Tomcat and Spring maybe be the mainstream enterprise server? Or do you think that there will be still place for heavy and complex, full-blown J2EE servers?

Well that is certainly a question that got to the point. I think the pretty clear answer to that question as to will Spring and Tomcat become the mainstream enterprise Java platform? The answer is, Spring and Tomcat is the mainstream enterprise Java platform. I can't actually share the numbers, but we have actually commissioned some research from analyst firms, and basically what all those studies have shown is that Spring and Tomcat is more prevalent than for example WebSphere, WebLogic, so I think it is pretty clear that a change has happened in the market. There are a number of data points to verify this.

I mean, rather than just take my word for it, you can for example look at job listings and you will find more jobs requiring Spring than requiring EJB. With respect to the J2EE or Java EE platform I don't think it is dead, I think the profiles can keep it alive. I think the full blown application server is dead and frankly I think that's a good thing. That's not to say for example that there isn't value in products like WebSphere and WebLogic.

There is value in those products, but I think people want to consume that value in different ways. People don't want to have something that really is pretty big and bloated shoved down their throat -- they want to be able to pick and choose. And indeed if you look for example at some of the initiatives that those vendors are taking, like for example BEA's MSA or Micro Services Architecture which is using OSGi.

They are actually changing the products to make them more modular. I think it is pretty clear that the Java EE application server was something that was designed by committee; it never really solved the problems that it was intended to solve, and the world is changing in a way that makes it even less relevant than it used to be. So for example with the rise of SOA there are fewer and fewer applications that kind of fit that stovepipe architecture. With respect to specific component technologies of Java EE, I think some of them have a bright future, I think others of them don't. I think some that clearly have a strong future and remain very relevant include the servlet API, it's still very fundamental.

A lot of technologies or APIs like JMS and JTA define the fundamental middleware contracts; I think those will continue to play a very important role. JPA I think is likely to be successful. I think with respect to EJB, I think my views are pretty well known on it. I mean EJB is just a bad technology. I can't quite understand the desire that, at least Sun and some of the vendors seem to have to keep EJB alive. I think it has reached the point where it has a negative brand value. So for example a surprising number of large organizations like banks ban the use of EJB now. And realistically I think there were two choices: one was to either decide that maybe we should just end-of-life this, and the other was to accept that there was no point in backward compatibility with failed previous versions, and they start from scratch; that something obviously could be more successful without the baggage.

The benefits of OSGi for servers or making IDEs are clear, but what is the opportunity for application developers with OSGi?

The opportunity for application developers are really the similar benefits that you get with sever infrastructure. So one of the benefits that you can get is, when we are talking about modularity and of course running just what you need instead of a more heavyweight platform, OSGi is a technology that can literally just start those bundles at runtime that you need to do something. So computers are much better than people at working out… If you enable them to work out exactly what they need to load to do something, they will do an extremely good job of it.

So I think one of the key benefits that we can see is, achieve more modular middleware platforms with just that set of components are loaded in the server, to achieve a particular goal. Which means that I think we'll see, in a year or two's time, we'll see full-blown enterprise platforms that can do anything you like, but actually start up a lot faster than what we have right now. I think the benefits such as versioning and hot deployment will be very important. So for example the problem of version conflict in enterprise Java is gradually getting worse and worse.

I think pretty much everyone has experienced the problem where they have seen a clash between different projects that are using different open source libraries. As an example of that, Hibernate 3, the first time it ran a query would cause a WebLogic 8.1 or 9 server to quit, literally quit, with a console message saying: "CharScanner; panic". The reason that happened was because WebLogic used ANTLR and so did Hibernate; but they used different versions of ANTLR. Those kind of problems are getting worse and worse as even commercial application servers use more and more open source.

Basically the solution to that in Java EE is "Oh, we haven't gotten to that yet, so just use whatever duct tape the vendor gave you". So there is a variety of pretty horrible hacks that you can use to invert class loading order, and they are not portable and they are really not a strategic solution. It is a band-aid solution. If you look at OSGi, it really solves that problem cleanly. It solves it in a standard way that is portable between different environments. It's predictable, it is not a duct tape solution.

And that also allows you to do things like concurrently running the same application, different versions of the same class, if you need to do that; and also to give you the ability to do fine-grained redeployment of components of your business applications. So I think the really clear benefit will end up being improved uptime. You won't need to take down your application to replace a few classes in the billing system; you will be able to put in that subsystem at runtime. I think there is a lot of ease-of-use challenges that need to be solved to get there. So let me be perfectly clear that if you go and take Spring and Spring Dynamic Modules and OSGi right now, you're still going to find life fairly complex.

I think we need to gradually see more integrated products that pull all of this together into a single solution. But definitely I think the technology capabilities are there, and that OSGi will solve some problems like versioning and maintainability that Java EE has not done terribly well. I think in the future we'll see benefits of isolation, so for example integration between AspectJ load-time weaving and OSGi. So once you have a well-defined deployment model in terms of a bundle, which is independent of any particular environment like a Java EE server, you can start to do some really interesting things with load-time weaving such as automatic policy enforcement. I think it raises some very very interesting possibilities.

So going back to the discussion of acquisition, SpringSource has recently made their own acquisition with Covalent. Can you tell us a little more about that?

Yes, it appears we got a good deal because, at the time when we were working on the acquisition, Sun announced that they paid one billion dollars for the M in LAMP. Well we paid less than one billion dollars for the A! That's a little flippant, and obviously no one can actually own an Apache project, I mean we fully understand the Apache community. The acquisition of Covalent reflected a number of factors: firstly, like I think any acquisition that is going to succeed, it was driven by customers. So we had already discussed with Covalent customers who were talking to both companies and wanted from Covalent support for Tomcat and possibly the Apache web server, and wanted from SpringSource support for Spring. So, it was very clear that we had to do some kind of partnership.

For those who may not be familiar with Covalent, they are the leading provider of support and services for Tomcat and for the Apache web server. So when you see the fact that, as I mentioned, the combination of Spring and Tomcat is really the most popular platform now for enterprise Java deployment, it really made a lot of sense for us to bring together the ability to provide the highest quality services for that combination. Some other fact were that there are a lot of shared values between the two companies. So obviously I have been pretty vocal in the past about my very strong belief that you can only provide high-quality support for open source projects if you are actively involved in contributing to those projects and contributing intellectual property. Covalent have exactly the same attitude.

So for example some of the Covalent engineers include the most active committer on Tomcat; and also Bill Rowe, who wrote very large parts of Apache 2 and continues to be incredibly involved in Apache development. So it has actually been a very smooth acquisition in terms of shared attitudes and people who have a lot of mutual respect. Finally it was a pretty natural step in terms of our ambitions to be the leading company in enterprise Java open source, and it was kind of a no-brainer to have an opportunity to bring together support for the components that seem to be becoming a de facto standard for enterprise Java.

Speaking a little bit more about the future, what's in store for the Spring Framework 3.0?

The Spring Framework 3.0 will continue the substantial enhancements that were already introduced in Spring MVC in 2.5. Probably the biggest change from the end-user perspective in 2.5 was pretty extensive use of annotations, so rolling out the ability to use annotations across both the Spring IoC container and Spring MVC. In Spring 3.0 we'll be furthering that with hopefully a convergence in the programming model between MVC and Web Flow. So we are looking toward providing a single programming model that scales through web MVC classic request-response navigation through to the directed navigation that Spring Web Flow provides, with a consistent programming model. We are also looking at introducing support for REST, so for example processing in Spring MVC RESTful URLs, and we are also likely to be dropping support for Java versions before Java 5. I mean that won't produce a… We already have extensive support for Java 5 and indeed Java 6, so that will only have a modest impact, but it certainly will make it easier for us, to maintain a codebase that is purely Java 5 and above.

One last question that I have is, are there any new projects planned for the Spring portfolio?

The most recent addition was Spring Integration which was announced in December at The Spring Experience. This provides a model for enterprise integration built of course on the Spring component model. It also has what we believe to be a fairly innovative programming model that extensively uses annotations to very concisely handle patterns like aggregation, transformation and routing. We don't have any more new projects that we expect to add to the Spring portfolio in the near term, but as you have seen with a number of projects that are going to go in final releases in the next couple of months, we have been extremely active across the Spring portfolio overall. SpringSource will certainly continue to announce new products and certainly by the JavaOne time scale we will have some pretty significant new products that we'll be demoing.