Bio Rod Johnson is the General Manager of the SpringSource division of VMware. Previously Johnson served as CEO of SpringSource since the company's inception and has more than 12 years of technology and management experience. Johnson, an authority in the enterprise Java world, conceived of and initiated the development of Spring. He is a thought leader on open source software.
SpringOne 2GX is a collocated event covering the entire Spring ecosystem and Groovy/Grails technologies. SpringOne 2GX is a one-of-a-kind conference for application developers, solution architects, web operations and IT teams who develop, deploy and manage business applications. This is the most important Java event of 2010, especially for anyone using Spring technologies, Groovy & Grails, or Tomcat. Whether you're building and running mission-critical business applications or designing the next killer cloud application, SpringOne 2GX will keep you up to date with the latest enterprise technology.
We think it's a good thing to say more commitment to open source Java so broadly speaking we welcome the commitment of different companies to that.
I think the competition and choice are good so I think it would be very unfortunate if Harmony didn't go forward. I think there is a lot of value there so we'll see how it plays out, but certainly I think Harmony has been a positive thing, the existence of Harmony has been a positive thing for the Java community and I certainly hope it that C continues at the Apache Foundation.
I would characterise the comments as comments from competing vendors rather than comments from the community. But anyway to address the question I don't think EE in any version versus Spring is an apples-to-apples comparison. I think it's frankly a fairly silly comparison. So if you want to run Java EE 6 server as Juergen pointed out recently in a blog, Spring works great in that environment and Spring adds value to that environment. But frankly if you look in the way Spring has evolved the scope of Spring is actually far broader today than the scope of EE. So for example if you want a component model that isn't tied to a traditional application server, if you want a component model you can for example run in Google App Engine or VMforce Spring meets that need.
If you want a component model that’s extensible with truly sophisticated security: Spring. If you want a component model that extends to modern integration patterns as a natural extension of that POJO model: Spring integration. If you want a component model that extends to batch processing Spring framework and Spring Batch. If you want a choice of full-featured web frameworks for example Integration with up and coming technologies like Google Web Toolkit. If you want productivity solutions like Spring Roo and Grails, I think frankly this is misleading to think that just because Java EE6 now finally has a credible dependency injection capability and almost credible AOP/interception capability that it is a replacement for Spring. I mean frankly I think that is not a particularly credible assertion.
We have announced several at this show, Ryan, and I think it's important to step back and look at the motivation for some of what we are doing. As I pointed out in my opening keynote we are not in Kansas anymore. we spent about a decade in trying to write transactional web applications, probably to a primarily overwhelmingly to a single relational database, did a little bit of a messaging on the side with a little bit of JMS here and there but basically pretty traditional applications with a request response paradigm from supporting Firefox and Internet Explorer.
What we've seen in the last couple of years is there are a lot of powerful forces for change. So for example deployment in the traditional datacenter is not longer the only option. People want to be able to deploy to Google App Engine, to EC2 potentially to things like VMforce. So Cloud either public or private Cloud it's becoming very important. We're also seeing that it's no longer a world about Netscape, Firefox, Internet Explorer. It is a world where you have different non-traditional device types and you need to be able to provide a rich experience for all those device types. It's a world where not all the new data is going into the relational database.
It is an astonishing proliferation of data out there now and a lot of that data is not going to go in a relational database. Take for example RFID sensors. There are billions of RFID sensors all generating data. And there is going to be an increasing amount of data that goes into other stores. And we need to be able to program in a productive effective way with these new types of data stores.
There is also social media which now I'm just astonished that even when I use my banking application, I see Facebook, Twitter integration there and of course you've got OAuth, which is a very convenient way of handling Identity across these kind of services. So, now coming back to the specific Spring projects, we’re really looking at this context and the fact that there are a whole lot of new challenges that we frankly want to be able to help developers address. We want to make Java developers able to be very productive in building applications and serve different client types.
We want to be able to make Java developers be able to work successfully and productively with non-relational data stores such as Redis, Neo4J, Mongo, Couch DDB, Hadoop potentially -- a very wide range of potential stores. And we want to be able to bring the familiar Spring programming model to help developers address this range of solutions.First fortunately Spring is very flexible. I mean the core ideas in Spring, dependency injection and AOP along with those portable service abstractions that Spring provides. It turns out that they can bring value to many of these areas. So, for example, if you look at what we announced with Neo4J the graph database.
We made use of the Spring data access patterns and also the AspectJ AOP technology that complements Spring and we were able to provide a really, really familiar simple programming model to that database which isn't very familiar to most Java developers.
We've always believed that there has to be a mix of leading the community and following the community. So certainly there are things that we've done in Spring that the community didn't ask for. So the community never asked for dependency injection. The community never asked for AOP, yet obviously Spring transaction management is based on AOP and millions of developer use it. On the other hand the community does often have incredibly good ideas about how to evolve technology and the community gives incredibly valuable feedback on how useful particular technologies are.
So, in terms of these newer projects I think it was more along the leadership side where at the beginning of this year Adrian Colyer and myself spent a lot of time thinking about what is going to be important? So let's not just focus on what we've been doing for the last few years and which frankly I think Spring does a terrific job at. Let's look at these new challenges that are coming up and see if we can really bring value there. And this was when we looked at those priorities and I mean the themes that we've been executing on for the whole year. Which I constantly stress to my team: productivity. You can never do enough in productivity. Really in technologies and improved developer productivity are incredibly important no matter what you want to do. So, hence our investment in Grails, in Spring Roo and SpringSource Tool Suite.
And, secondly, addressing these new areas. So bringing the power of Spring Framework to, for example, bring Spring Security and OAuth together. To bring what we've learned about data access over the last few years to some of these non-relational stores. And also to address new integration patterns which are becoming increasingly important through projects like Spring Integration and Spring Batch. So it was very much a process where we thought long and hard about what we thought was going to be increasingly important. One thing though to come back to the concept of community, Ryan, that I think is really interesting is, particularly in the area of non relational databases, we now are doing some fantastic collaborations with the different communities around some of the different products.
So for example the Neo4J guys are vigorously writing a Spring Roo add-on. They are vigorously contributing to the Spring Integration with Neo4J and we expect that will happen with other communities and vendors. It's actually been really interesting that as we've done this things we've discovered that it really energises this whole group of people that have something valuable to contribute to Spring.
Regardless of what you want to do productivity is central. So whether you want to deploy to WebSphere, you want to deploy to tc Sever, you want to deploy a public or private Cloud, the cost of people is today one of the major costs of producing software. And it's not merely a question of the actual cost of the people; it's a question of how effective they are. Are they focused on doing useful things? Are they focused on implementing business requirements and delivering value. I firmly believe anything and everything we can do to improve productivity is just about the number one task, regardless of any other goals that we have in mind.
I think there is tremendous opportunity to improve productivity on the JVM. So I'm very proud of what we achieved with both Grails and with Spring Roo and I think realistically the experience you can get with those productivity tools I think is a surprise to a lot a people that haven't used them. Java and JVM productivity it’s really coming along if you use modern technologies. I think though the emphasis on those tools also reflects our belief that you can't think purely about software on a point in time basis.
So you know sure: you use Spring you make your code simpler. However you also need to consider how do you work. So it's not just about here is a point in time, I've got a software project where the source code is simpler. That's great! It's part of the solution but it's not the whole solution. You also need to look at how the developers work. How can they be really productive and effective, how can they create applications, how can they work to maintain those applications and how can they potentially transition those applications to a deployed environment. So I think over time we’ve extended our view from it being about the framework or the server at a point in time to also addressing the way in which developers work and just trying to do what we can to make them more productive and effective.
7. Java 7 has taken a lot longer to show up than most observers expected. And as a result it seems that the pace of change in the Java language has slowed down and there seems to be a lot of interest of finding alternatives. Is Grails something which allows for a greater productivity beyond which you can achieve within Java and does having Groovy as a basis for that allow more innovation while the Java language seems to stay static?
Well, I think I agree the Java 7 is taking too long. However, I think Java is a mature language and as things mature they get more and more uses and it does become difficult to move them forward at a rapid pace. So a couple of things I would point out: I believe that it's absolutely appropriate that Groovy can move faster and Groovy provides this place for innovation that can move faster than the Java language spec. I think that is absolutely normal and healthy, and I think that's a fantastic thing for the JVM because the JVM is in fact bigger than Java. Also I think it is important to note that a lot of innovation can happen in frameworks and doesn't need to happen in the language.
So for example some of the things that are irritations in the Java language Spring Roo addresses. Like two string methods, Java Bean methods, I mean they just become an absolute non issue with Spring Roo. With respect to whether you can do things in Grails and Groovy that you'll never be able to do in Java, you absolutely can. I think it's essentially a religious question: whether or not developers prefer dynamic or statically type languages. I don't think there's any right answer to this. If you look at dynamic languages, if you look for example at doing OR mapping or in fact mapping to non relational stores using GORM, it's incredibly concise.
Because it really takes advantage of capabilities that will almost certainly never exist in Java, because Java is a statically typed language. But on the other hand obviously statically typed languages do have some real advantages. You get a complete model of your application, which you for example with Spring Roo can do useful stuff with in terms of round tripping code generation. So we see this is a religious debate and we don't want to take sides in religious debates. What I like to drape on my team is that I don't want to go and try to convert developers to a different religion; I just want to go and build a church that for each group of developers they can come along and attend.
So, I think that realistically the value proposition of Groovy is always going to differ from that of Java and I think it's extremely important to the future of the JVM that that dynamic language proposition exists on the JVM. I think Groovy is very, very compelling for a dynamic language for a number of reasons. One is that it provides an incremental adoption path. So the first time a lot of developers sit down to write a class in Groovy, it's going to look pretty much like a Java class and that will work. And they now suddenly discover that they can probably type about the third of number of characters and they will still have the same functionality implemented in Groovy.
Then of course there is a way that supports annotations, there is the way which in fully participates in the inheritance model. So, I think that unique closeness to Java both makes it easy to learn and makes it very valuable. It also means that for example if you are building a Grails application, if you want the benefits that Java has for certain things, just go implement that class in Java and I think that's a very strong value proposition for Grails and Groovy.
8. So at SpringOne, a partnership with Google was announced which involved three different things. What brought about that partnership and what does that provide for both SpringSource and Google users?
I think one of the things that brought about the partnership is a shared vision of trying to serve the needs of modern applications. So, Google App Engine is a deployment possibility for modern applications and I think if you look beyond the shared vision, if you look at the motivation for each side, we've always been very committed to portability. We want and value the ability of Spring developers to deploy to the destination of their choice. So for example if you look at the Spring Framework code, despite the fact that we successfully sell our own tc server product there are thousands of lines of code in Spring to optimize it for deployments to WebLogic and WebSphere.
We've always targeted a range of deployment choices. And now we are at the point where we see that there are developers that want to deploy the Google App Engine and this absolutely sits with the Spring portability mission. Secondly, we are very interested in the Google Web Toolkit technology. We believe that it's very compelling, it's one of the more interesting new technologies in Java certainly in the web interface space, it's probably the most interesting single new technology. And we want to make sure that for Sprig users it's very easy to use that technology.
For Google the motivation was they look at the two and a half million Spring developers out there and they want those developers to be able to come on board or at least have the choice of coming onboard to Google App Engine. And secondly both the Google team behind Google Web Tool Kit and the Spring team felt that Spring Roo and Google Web Tool Kit were a match made in heaven. I think it's fair to say that Google Web Tool Kit team fell in love with Spring Roo. If you look at the model they have where you specify most of your users interface by authoring Java code it sits really well with this sophisticated round tripping code generation that Spring Roo provides.
So Spring Roo does have a complete domain model, generates and maintains artefacts based on the evolution of that domain model. And so it's been possible to extend that to generate the artefacts of a GWT [Google Web Toolkit] web interface and to support round tripping in taking that forward. This not only makes the process of building the GWT applications far simpler, but it also insures that users can easily benefit from what Google regard as best practices. So best practices with respect to authoring GWT applications have changed. Google are now promoting different best practices and I think they are very excited that Spring Roo is not merely a simplifying technology. It is a prescriptive technology where essentially it allows developers very easily to be directed in the path of GWT best practices.
We think this is a significant benefit for the Spring users. So I mean there are two keys benefits for our community. Firstly you can take advantage of this interesting new web technology; you can do it very productively. And, secondly, you get yet another choice in the portable set of destinations out there for Spring apps you can potentially deploy to Google App Engine.
As we grow our middleware portfolio we are really focusing on technologies that have a value in cloud computing as well as in traditional enterprise deployment. Rabbit really fits that bill. I mean it's widely used for example on Amazon. It's widely used by some of the PaaS [Platform-as-a-Service] vendors out there and it's used by some of our customers at extreme scale, spanning multiple datacenters. It also is now getting increasing use in the enterprise particularly in the financial community.
Basically AMQP and Rabbit grew out of the financial community in London and New York and we see significant enterprise adoption there. So we felt that integration between applications and asynchronies communication is becoming more and more important. As applications move into the Cloud as they become all connected with social networks etc., there really is more and more of a requirement on those technologies that make that communication possible. We very clearly felt that we needed to have a message broker technology and we looked at the space and we were very, very impressed with the quality and the user base of Rabbit. We've been very happy to have the Rabbit technology in house and have that team onboard.
The GemStone acquisition was really driven by similar concerns about where are we going. And again it comes back to this need to communicate potentially between different datacenters, this need to be able to deliver dynamic scalability to applications running in the Cloud. The GemFire technology is very powerful. It’s best described as a data fabric technology, a lot of developers think of it as a distributed cache but in fact it can do far more than that. So amongst other things we see many enterprises using that technology to offload substantial amounts of work from a relational database. We see them using it to get dramatically lower response times in working with very large datasets.
For this reason it's extremely popular in defence and intelligence. We believe that when it comes to dynamic scaling the ability for example to cluster state in the middleware node becomes critical and now of course we’re adding a GemFire session distribution mechanism as an option to our tc Server product. So we felt that this area of data grid, data fabric, distributed caching is extremely important and we looked at the technologies out there and we felt that GemFire was an outstanding technology. So, for example, the phrase "mission critical" tends to be bandied around. The military truly do do things that are "mission critical."
They use GemFire to track their assets in an operational theatre. That genuinely is "mission critical" and that software has proven itself as being robust and reliable enough to support that. We are now of course enhancing the Spring programming model to take advantage of data grid technologies. We're doing this in a way that would make all data grids much easier for Spring users to use. So for example if you want to use Coherence or Ehcache, as I said we are committed to portability, that's fine. We don't want to lock you in to our stack. But I think the end result of this is GemFire will be very easy to use for the Spring community and it would also benefit users of any data grid technology.
Spring Data consists of a set of efforts around non-relational databases and also around working with data grid technology and enhancing the core Spring Framework to have that data grid integration out of the box. So for example things like transparent caching delivered at any layer of your application delivered transparently by AOP. It's a very good match with the Spring Framework. Of course there use to be a Spring Modules caching project many years ago. Unfortunately it was a community-led project and the developer of that project ceased to have time to contribute to it. But it was quite a popular project. Now it's great that we've been able to come back and deliver a high quality solution and bring that to the Spring Framework core.
I thought that was pretty cool! And I wrote the first version of that code, too, so I'm glad you liked it! It's achieved using AspectJ. We've always felt that there is a great synergy between Spring and Aspect J. We are in the business of making a POJO- based programming model fulfill critical needs and obviously Spring is very good at doing that, aspect oriented programming in general is very good at doing that. And AspectJ really supplements and complements Spring AOP being able to handle things that you can't handle with a proxy- based infrastructure. So essentially what's happening there is we complement the JPA provider.
So when I demonstrated how you can persist an entity to both a relational store with some parts of the object model being persisted to a graph database, what was happening was the JPA provider was perfectly happily persisting all the fields at it was told were non transient. So as far as it's concern that's all fine; it's doing what it knows about. But on the other hand the fields that had annotations that related to Neo4J and the Spring Neo4J integration, those fields were benefiting from special behaviour that was introduced using an aspect. So for example field "reads" and "writes" are advised by AspectJ and they are underneath the covers using the Neo4J API to retrieve the underlying node value or the underlying relationship value.
So I think it's actually a really cool illustration of the way in which AOP can help you get a really nice, elegant, transparent programming model. And of course it completely externalises any need to use the Neo4J API. I think it's interesting that we've had aspect-oriented programming technology in Spring since probably for seven years now, over seven years. We have integrated very closely with Aspect J for five years since Spring 2.0 and of course Adrian Colyer before he become CTO at SpringSource was the lead of AspectJ. But it's actually over the last year that I think the true power of AspectJ started to be felt across a lot of things we do.
And it really comes down to productivity. So to give you some examples Spring Roo -- Spring Roo addresses the productivity challenges of a statically typed language by generating aspects and bringing additional capabilities into Java classes through aspects. Spring Insight is a very cool technology that enables you to visualize the performance of Spring applications when they are deployed to our tc Server product that uses AspectJ load time weaving. And of course the Neo4J and very likely some of the other non-relational persistence technology were getting that unique mixing and matching capability using aspects. So I think that AspectJ has become a really important enabling technology going forward.
And as a result of all those initiatives we've invested very heavily in the tooling, in the compiler and also in the performance of load time weaving. Si I think it had the added advantage that it's really moved the AspectJ project ahead as well.
13. One of the challenges that I remember being mentioned with Aspects, when they first came out there were described they are very useful but it was very difficult for developers to wrap their brain around how Aspects work and how they mutated the code and they got unexpected results. Do you think that this kind of encapsulation of a lot of this aspect work within the framework is a good way to address that concern?
That's a really good question. And I think that what you might term applied aspects are incredibly important and they are going to account for the majority of the user Aspects. So I would hazard a guess that by far the most important and influential aspect ever is the Spring transaction management capability and a large number of the people who use that in the development community probably don't know or care that it's based on AOP. They just see that it solves a really useful problem for them and does it in a simple way. I think that however there are a gradually increasing number of developers who see the benefit of surmounting that intellectual hurdle and just thinking about what aspect technology can do.
I think when people say that aspects can make code behaviours more confusing I think I say one of two things to that. One is that if that is indeed true they are using the aspect incorrectly and obviously if you introduce a technology where it doesn't belong it makes life more complex. But more likely they are doing an incorrect accounting where for example if you’ve got a cross cutting concern, if you have for example a piece of code like say a security check that you need to apply in hundreds of places. Before you say "well this Aspect is hard to understand because it changes stuff,” think about what it looks like without the aspect and think about that code duplication.
Also think about what happens when you discover you have a bug in all your duplicated code. You can fix the aspect when you've modularized it. You can fix it in a single place. Whereas if you’ve got it sprayed it around your code base you will find that much harder. I mean I still think that aspects in terms of custom coding absolutely have a place. And I think it's a very powerful and capable technology. Certainly think it shouldn't be overused, I think what we've establish with Spring Roo and Spring Insight is we can give you a lot of value even if you never want to go touch aspects yourself. But interestingly of course Spring Roo by default enables AspectJ in all projects. So if you want to go and experiment with custom aspects it's a pretty interesting opportunity to do that with almost zero costs.
Firstly we took the DM server project to Eclipse. So it's now at the Eclipse Foundation it is the Virgo project, we contribute to it and some other companies contribute to it. I think over time it’s fair to say that we've reassessed OSGI and we've concluded that OSGI is a valuable technology for a certain niche rather than the main stream technology. This was the result of a lot of soul-searching and I think one of the things that was quite decisive is the fact that we felt we simply could not make OSGi as simple as we like Spring related technologies to be.
Certainly the Spring dynamic modules project and the DM Server/Virgo project make OSGi simpler than it is without Spring and without that server but it is not as simple as simply running a web application and deploying it on tc Server. So we came to the conclusion that if you have advanced modularity requirements, for example you need dynamic reloading of modules, or alternatively you need to run concurrently different versions in the same jar, in the same serve, OSGi is a great fit for things like that.
However the typical user for example who wants to deploy web applications, wants a server with a small footprint that starts up quickly, that is easy to use and has strong management and diagnostic capability. That's why we find tc Server as an extremely popular product. So if you have a sever that's got a memory footprint well under 100 megabytes it doesn't really matter too much whether or not you try to modularize it. So for example if you have WebSphere, something that size, you probably want to modularize it.
If you have tc Server which is based on Tomcat , it is not so crucial to actually modularize the sever. We see only minority of costumers who really want to modularize their applications and I think we learned that we got very excited about in fact was for a niche rather than for the mainstream.
Code2Cloud brings the Cloud to Java developers. Another way of thinking of it it's actually an extension of Eclipse and SpringSource Tool Suite that moves your development environment forward to link up the developer desktop with the deployment destination. So if we step back and think of what we've achieved in the last few years with Spring Framework, Spring Roo, Grails and STS [SpringSource Tool Suite] we think we've made developers measurably more productive. So what happens on the developers desktop we’ve really improved that a lot. We've provided a variety of deployment choices so for example TC Server VMforce of course the other choice of destination we support.
But if you look at what happens between the developer's desktop and the deployment destination the process typically requires a good deal of tedious integration. Especially if we think of Cloud deployment where we’re deploying to a Cloud because we want to get away from servers we configure ourselves, it becomes obvious that if you don't want to be provisioning servers yourself to run your application server why do you want to be provisioning servers that will run your issue tracker? Why do you want to be provisioning servers that will run Subversion or Git? And why do you want to provision servers that will run Hudson for continuous integration?
So we came to the conclusion that firstly it was very important to host those things in the Cloud and secondly there needs to be a really strong integration between the developer desktop, the development collaboration services hosted in the Cloud in Code2Cloud, and the choice of deployment destinations. So really it's a bridge between our technologies that the developer users and the choice of Cloud deployment destinations that we are supporting. We feel firstly it would make developers way more productive, I mean just go download SpringSource Tool Suite and you're done.
If you want to create a new project just check a box that says you want the sources and you want the issues and continuous integration set up and deploy too your choice of destination. All are linked with a single sign on. Very, very simple. But secondly I think beyond the immediate goal of simplification, there is the opportunity here for breakthrough innovation. So one of the things that we demonstrated is the way in which with Spring Insight we can identify a performance problem in the deployed application and we can go back to the issue tracker and propagate all the way to a new Mylyn task context in STS showing exactly the line of code that appears to be responsible for the performance problem. Similarly we can provide a unified view of how much an application costs.
We can see the resources that it’s consuming in the Cloud, we can see the amount of time that developers are spending right in the IDE. We can put that together and potentially say this application is costing you so much, the development is costing this much and this breaks down across like all things related to the IPhone client are costing you this much. All thing relating to the Android client they are costing you this much. So we can also integrate with testing technologies. I think there are a lot of partnerships that we can do around this for example vendors in the quality management space, vendors and the Agile project management space.
So we see Code2Cloud is a really exciting initiative that initially will make life easier but secondly will create a partner ecosystem for VMware that brings a lot of innovation and benefit to developers. Again it comes back to that point, Ryan, that I made earlier; it's not just about point in time. You really need to be able to make developers work more productively.
I think we learned a lot from Cloud Foundry and that was definitely one of the inputs. The initial ideas, as I think Mik Kersten mentioned on his blog behind Code2Cloud, resulted from a very enjoyable lunch we had out in Woodside shaking our brains up driving around an incredibly windy road. For those who know the Bay area it's actually beyond Woodside, it's La Honda. There is this wonderful little biker bar called Apple Jack’s in La Honda. And Mik and I usually go out there for lunch. I remember actually one of the last times his new iPad caused quite a stir because they don't see a lot of iPads out there. So anyway we were just tossing some ideas around and suddenly it dawned on me that, wow if we really put our capabilities together we can build something here that's truly innovative. I'd say that's about a year ago and I'm impressed that we've been able to create so much of that software in the meantime.
I think we will definitely get community contributions. Code2Cloud exposes RESTful API's. So there are essentially three interfaces: There is the STS experience that uses Mylyn and that itself talks over REST to Code2Cloud. Then there is a standard that Tasktop and IBM have driven called OSLC for integrating application lifecycle tools and Code2Cloud supports that. So I think there are a number of opportunities for folk to write connectors to Code2Cloud and absolutely we would welcome community contributions and hopefully will get community members involved in actually contributing the core code as well. We are also contributing to projects such as Hudson as result to this initiative.
Thank you Ryan!