Spring Getting into a Groove with Groovy: SpringSource Acquires G2One

You may also download this file. Running time: 00:20:04
On November 11, 2008, Springsource announced the acquisition of G2One, Inc. Spring has been a significant force in Java since Rod Johnson wrote Expert One-on-One J2EE Design and Development in 2002. This book was a rallying call for Java developers who were fed up with the overly complex EJB specifications emerging from Sun Microsystems in the early part of this decade. Since 2002, Spring has become the center of Java innovation, and whenever you attend a conference like JavaOne, it is clear that most server-side Java developers look to technologies like Spring and Hibernate before they look to many of the standards emerging from the JCP or from Sun.

Graeme Rocher is a co-founder of the Grails web application framework and a member of the JSR-241 (Groovy) Expert Group. As the CTO of G2One, he works closely with people like Guillaume Laforge, also with G2One, to support and implement both the Groovy language and Groovy on Grails. In this interview, I wanted to give Rod and Graeme a chance to talk about the differences between Groovy and JRuby, and the reasons why someone would develop in Grails over running Rails in JRuby.
Interview Transcript
Rod Johnson: The news is that SpringSource is announcing the acquisition of G2One, the company behind Grails and Groovy. The motivations for this are firstly that we think that Grails is a very interesting technology in the Enterprise Java space.
Secondly, that we do see a growth of interest in dynamic languages. We think that's a pretty broad movement across the IT industry. You are seeing a significant number of people who like dynamic languages. We are still, of course, completely committed to providing excellent solutions around Java but we want to make sure that we can reach out to those - that audience and let them rate the full benefits of Spring.
Thirdly, Grails is a technology that is built on Spring. Grails is built on Spring, it is a technology that really enables people who prefer dynamic languages to enjoy that experience but do so in a way that gives me full access to the benefits of the Spring component model and all that Enterprise Java has to offer.
And also we're very excited by the style and explosive growth of the Grails community. I tend to avoid words like explosive. In this case I feel that it's very appropriate. Twelve months ago Grail's downloads were running around 7,000 per month, this month they've been steadily growing to an excess of 70,000 per month. That not only is truly explosive growth but it means that Grails has one of the largest communities out there in terms of Enterprise Java. There's really only a handful of projects, of course, including Spring itself, that have more downloads than that.
So we're very excited about the scale of the community and also I think that's a massive validation is the importance of Grails as a technology. SpringSource has over time been steadily broadening what it has to offer to its users and customers. We've been doing that though enhancements to the Spring framework though steadily increasing the scope of what we have to offer, in Spring projects though the introduction of the dm Server, application server though our acquisition of Covalent and now with our acquisition of G2One we're reaching out to a new audience that is very interested in dynamic language technologies.
We see this as a very natural and evolutionary part of SpringSource's mission to be the leading provider of Enterprise Java software.
Tim O'Brien: So in terms of your existing customer base, how many customers that use Spring products are already using Grails?
RJ: We do have some shared customers. One example of the shared customer is LinkedIn. LinkedIn is a very heavy Spring user. Their whole system is built on Spring by our SpringSource Enterprise customers. So, you know, they subscribe to our Enterprise value ads above Spring. They also value their 24/7 support experience that they can get and they also use Grails and are a G2One customer. So that's an example of a shared customer.
We are seeing an increasing number of SpringSource customers that are asking about Grails and are very interested in looking at whether or not Grails can help them. Of course, if you look at the G2One customer base every G2One customer was obviously already using Spring because Grails is built on Spring.
TO: ...about the difference between something like Grails and something like Rails, Rails has been very popular and there's also JRuby from Charles Oliver Nutter, but there is something of an impedance mismatch between the Java platform and the framework. Talk to me about the differences. What makes Grails different from Rails, you know, at a very shallow level?
Graeme Rocher: So essentially the difference is already two-fold. One relates to the fact that it's built on the Groovy language. The Groovy language itself has a much tied integration with the Java platform in that it supports bidirectional relationship between Java and Groovy.
So with a language like JRuby it's quite easy to call Java from JRuby, going the other way is a lot tricker. With Groovy, on the other hand, you have a joint compiler, Java code can reference Groovy code, Groovy code can reference Java code.
Groovy is also the only dynamic language on the JVM at the moment that supports the full set of Java 5 features needed to support Enterprise Java. So we're talking about things like annotations, generics, and if you look at the latest specifications coming out of the Java community process I was just reading through Web Beans today, they're making extensive use of things like annotations and generics and currently Groovy is the only dynamic language that can take advantage of those.
In terms of Grails, well, Grails is just built on top of the Enterprise Java stock of Spring and of course, Hibernate and it's - it essentially is a plug-in system that uses Spring internally.
And the great thing is that it then benefits from all the great features that Spring offers so it builds on Spring's transaction demarcation layer, it builds on Spring's component model, it depends the injection container and it means that, for example, Rod was just talking about LinkedIn, LinkedIn is a prime example of where they have a Ruby on Rails application that needs to talk to their backend by XML web services whilst their Grails application is just embedded and talks directly to their Spring beans without any extra layers in between.
TO: So the main concrete difference for a company like LinkedIn is in their Rails app. They have to build some sort of rest layer that's in Java and then have the Rails app talk to that Rails layer. But in Grails they can just go directly to something like a Spring managed DAO?
GR: Absolutely, because Grails is built on Spring so they're just reusing the same Spring bean definitions the same application context that runs their entire back end.
But, you know, there's a whole lot of other differences performance characteristics are different. Grails is a lot more performant. There is - there are features in Grails that are important to Enterprise customers that are missing in Rails, things like conversational statement management, transaction demarkation, etcetera.
RJ: I think certainly if you look at Ruby on Rails, Rails introduced a number of very interesting ideas. For example, the extensive use of convention or the configuration, the kind of productivity and scaffolding tools that they provide. All of that is very interesting. So that certainly was a positive side. On the negative side there are really a number of things that are highly problematic for Enterprise developers looking to build applications in Rails.
Firstly, Activerecord really lacks the scalability and sophistication of our mapping solutions in Java. That is something that is absolutely not a problem for Grails. Grails can leverage the best that is available in Java or mapping. Secondly, as Graeme's already alluded to the performance benefits. Thirdly, if you are building an application with Ruby on Rails and you encountered the scalability issues, if you encountered the limitations of active record, if you encountered the problems of conversational state management, if you encounter a significantly to access Enterprise libraries that you already have authored in Java, you're gonna have to go rewrite your app. You're going to have to go rewrite your app in Java.
That is a big problem. With Grails it is completely different because you nearly hit a wall. Firstly, Grails itself is free of many of those restrictions but secondly if you ever need to write something in Java or if you ever need to use the full power of Spring you just go do that and you do that within your same application. There is absolutely no impedance mismatch, no jump into a different technology. So we feel that Grails is the technology that really picks up on a lot of the benefits that Rails delivered but he's actually much more Enterprise ready.
GR: In terms of Grails ability to do that is the fact that Groovy honors the Java class format. So that's something like JRuby does compile to byte code, it's not in the same class file format as you get with Java. So with something like Groovy, Groovy can be used in conjunction with Enterprise data grids like Terracotta and Oracle Coherence or as well as being able to take advantage of all the Spring features that rely on the byte code format produced by Java and Groovy.
TO: How many programmers would you say a percentage of Java developers that you've come into contact with know Spring and how many know Groovy?
RJ: It's always hard to estimate the usage of open source technology. In respect to Java and Spring usage well over 5 million people have downloaded Spring. The surveys that we've commissioned from independent third-parties indicate that something like two-thirds of Enterprise Java developers are using Spring.
So clearly the penetration is extremely high. The penetration of Grails is lower but there's a couple of things to note about that, one is that Grails is enjoying, as I said, explosive growth. The second thing is that Grails is a technology that is actually bringing new people to the Java platform and this is a big part of what we're doing with it.
We feel frankly that developers that like to develop in Java and it fits the profile of traditional Enterprise Java developers, you know, what we give them the SpringSource technology is already fantastic. Of course, we're always looking to make it better, you know, it's pretty damn good. Whereas when you look at the kind of audience that Grails can attract we believe that a substantial part of that audience is people who are new to the Java platform, and we think that's a very exciting potential Grail to grow both our audience of users and customers and also the broader audience of Enterprise Java.
GR: You know, both the philosophy of Grails and the philosophy of Spring is to simplify the lives of developers. Some of those developers are obviously into dynamic languages, some of them are into statically-typed languages. Of course, more dynamic languages like Groovy offer a level of simplicity that is more difficult to obtain with a statically-typed language.
However Grails - and the result is, is that, you know, Grails is attracting as Rod said, developers from the PHP and Ruby on Rails communities to the JVM.
TO: Are there any other dynamic languages that SpringSource is also paying attention to?
RJ: Certainly, we are always monitoring other technologies out there. In Spring Framework 2.0 we actually allowed the ability to author any Spring Bean, any Spring managed object in a range of dynamic languages and still enjoy the full benefit of this Spring component model.
So we to some degree say Spring and dynamic languages is a bit like Microsoft, the CLR and the Microsoft.net framework. So if you're developing on the .net platform, you've got common language runtime, you've got a host of Enterprise services that are available to you. However, what language do you author in? Maybe you use VB.net, maybe you use Manage C++, maybe you use C#, and Microsoft essentially neutral on what language you use to implement those Enterprise services.
We do believe that Groovy is at present the most promising dynamic language on the JVM. So, you know, I think that it's fair to say that this acquisition indicates our faith in Groovy. Having said that however, you know, we will certainly continue to insure that Spring Framework and our other products work with different dynamic languages, you know, where that's technically feasible.
The key thing I think is that Groovy allows you to compile to a class file from a Groovy artifact and that's a big deal. As Graeme said, you also have access to annotation processing which is incredibly important now to just about any Java component model including Spring Framework itself. So there are a range of reasons that we think that Groovy is a great choice on the JVM.
TO: I'm going to ask you one more question and I'm asking the two of you because you both have had a large role in helping to shape the direction of the Java platform in the last few years. SpringSource recently was elected to, I think it was the Executive Committee of the JCP. Is that right?
RJ: We were elected to the Executive Committee.
TO: Right, so I guess I'd like both of you to talk about what is the state of Java. It's been something of a whipping boy for the industry for a few years. Could you just talk about what you would like to see happen next with the Java language?
RJ: That's a very good question. I'll take it first. I think to some degree the use of Java as a whipping boy, it reflects a number of fairly superficial factors. One is that... Java, ten years ago if you wanted to enhance your resume you probably wanted to jump from VB or C# to Java and that had a competitive benefit for you and you got to learn something new and interesting. Right now Java is a mature language; mature languages are less sexy to the cool kids who like playing rather than working. Now that may sound like a fairly critical statement but I mean that is a fact of life.
So, you know, I think part of it is inevitable that when a language becomes mainstream, when it becomes successful you do actually find that you get a bunch of people who just feel they need to go look for something else.
Secondly I think that a lot of the negativity around Java relates to previous generations of technology that failed and has since been completely abandoned. So, for example, the horrendous reputation that J2EE developed excessive complexity around the old entity bean and the old EJB model. I mean no one uses those technologies anymore. I mean, people develop in Spring now. Spring and Hibernate instead of using those obsolete technologies. So, you know, that criticism really doesn't apply.
I guess the first point I would make is that I do think that a lot of the attacks on Java are a bit exaggerated. However, having said that I do feel there are very real challenges and certainly in my position on the EC I will be working to help address those challenges.
There are specific challenges that I think about are if you look say at the effort Microsoft is putting into the effort C# language and they've gotten that platform. If you look at thinks like Link that is really interesting technology and they're frankly innovating faster than innovation is occurring in the Java language.
Innovation really is occurring in places like Spring and Grails in Java and I think that Sun really needs to be open - more open to embracing that kind of open source innovation. Secondly, I would like to see greater embrace of dynamic languages on the JVM because I think the JVM story shouldn't be just Java. Thirdly, I would really like to see some housekeeping and printing of API's that are not necessary. I think Java is unnecessarily bloated with old API's and packages that no one uses like the old AWT, Windowing Library I think we should take a long hard look at doing some house cleaning.
I think the death of Java like the death of Mark Twain has certainly been exaggerated. We feel that both in Java based technologies and also with Grails there's a tremendous amount we can do to improve the Java platform. But, you know, on the other hand it is always important to be vigilant. Graeme, what's your take on this?
GR: Yeah, my take is that, you know, as Rod said there's a lot of noise on blogs and so forth about how Java is coming to its slow and gradual death or whatever, but the reality is quite different. Essentially if you look at the way the Groovy developers see this, you know, languages like Ruby and Python and so forth exist outside of the JVM and have been imported as JRuby and Jython, but they exist outside.
Groovy, on the other hand, it was designed specifically to be used in conjunction with Java. So Groovy is not seen as a replacement for Java. The Groovy developers and Grail developers are very aware that, you know, it's about picking the right tool for the job and there is still many, many, many circumstances where Java is a fantastic tool for many performance critical aspects of Enterprise Java work out there. And that's the great thing about Groovy and Grails is that you can mix the dynamic nature of the language like Groovy with performance critical code within Java and you can really get the best of both worlds.
In terms of Sun and their position I think that, you know, given the nature of the economy at the moment all companies are under a lot of pressure at this moment and having to take a strong look at themselves. You know, it's not at all surprising that Sun is in that same situation. It doesn't mean Java is going anywhere anytime soon. No, I don't think so.
RJ: Yeah, I mean, I think would I like to see certain things going to the Java language at a faster rate? Would I like to see certain things taken out? Yes, absolutely and I'll be pushing for that on the EC. But do I think that it makes it impossible to produce, you know, huge benefits for users of Java technology? No, I don't. I think there's a tremendous amount more that we can do in Spring, in our server technologies, in Grails.
You know, I think that we've already achieved a lot in terms of improving productivity and the experience of running Java applications and I think there is a whole lot more we can still do.
Related Links: