I’m excited about this deal for many reasons.
Grails is a great fit with Spring and SpringSource technologies. Grails is built on Spring. It offers another route to adopt Spring, the de facto standard component model for enterprise Java. All the power of Spring (and Java) lies beneath the surface of every Grails based application—a key reason that Grails can scale to enterprise use, as well as a validation of Spring’s power and flexibility.
Like Spring, Grails is a technology that simplifies the lives of developers and makes them more productive. As our new tagline, Weapons for the war on Java complexity, reflects, simplification has always been core to what we’ve done as a company and as technologists. The values behind Grails are the values behind Spring and SpringSource.
However, Grails and Groovy exemplify those values in a different, complementary, way to our existing technologies. The choice of dynamic versus strongly typed languages is something of a religious debate. However, interest in dynamic languages is undoubtedly growing, and it’s important that we recognize this and cater for those who prefer dynamic languages, but still want the benefits that Spring has to offer. There’s plenty of buzz around Ruby on Rails. Grails—of course, benefiting from the experience of Ruby on Rails—offers the same benefits, but without the many serious impediments to use in the enterprise that face RoR. With Grails, you can enjoy rapid application development and programming in a dynamic language without needing to throw away your investment in Java middleware; without the need to make inefficient web services calls to talk to functionality coded in Java; without losing the benefits of sophisticated O/R mapping; without the risk of hitting a wall with scalability or enterprise capabilities; without adopting an unfamiliar programming language for all your coding. You get the positives, without the very real risks.
Groovy has unique benefits as a dynamic language on the Java platform. It’s the only dynamic language that can compile directly to Java .class files; it’s the only language that can be used mixed seamlessly with Java; it’s currently the only language that can process Java annotations, which are becoming central to modern use of Java; and it has a natural migration path from Java, rather than calling for a big, risky leap of faith. It’s also a promising language for implementing DSLs—an increasingly important issue.
We’re not alone in our excitement about Groovy and Grails. Over the last year, Grails has enjoyed explosive growth in its community. Downloads have increased 10x, from around 7K/month to around 70K, as tens of thousands of developers see for themselves the benefits of programming in Grails. Developers are the toughest (and best qualified) judges of technologies, and they are showing a remarkable degree of enthusiasm, with the Grails community now one of the largest in Java-based technologies.
Finally, G2One and Grails are an excellent cultural fit with SpringSource. As a business, G2One was based on the same model of success through innovation and exceptional service as is SpringSource. Like Spring, Grails is about leadership. Graeme Rocher and Guillaume Laforge have done an excellent job in building out the vision of Grails and Groovy, and I am proud to welcome the G2One team to SpringSource, to join with their new colleagues as they define the future of enterprise Java.
What does this mean to you?
If you’re a Grails user, the backing of a larger company should be a strong positive. If your organization is risk-averse, it should now be easier to advocate the use of Grails due to the backing of a bigger company. You now have access to a single vendor who can provide Grails, Spring and Tomcat support, without any risk that issues will fall down the cracks. Grails depends on Spring, and you can expect integration with SpringSource technologies to improve further.
You can expect to see Grails remain a largely autonomous project. Like Spring, Grails will remain portable. It will continue to progress against its roadmap, for the benefit of its community.
The Groovy community should also benefit. The project will continue along its planned path and you can expect improved tooling support, due to SpringSource’s greater resources and Eclipse expertise. As with Grails, it should become easier to advocate Groovy in the enterprise. You can expect more options for taking advantage of Groovy in your use of Spring and SpringSource technologies in general.
If you’re a Spring user, but are not interested in dynamic languages, don’t worry! We are doing this to reach out to another community of developers, not to force our existing Spring developers in a new direction.
We are putting more and more development effort behind the Spring Web Flow and Spring MVC web technologies. That investment is making them better and better for developers who chose to program in Java—and will also make them a better and better underpinning to Grails.