Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Interviews Laforge and Rocher Discuss the future of Groovy, Grails and Java

Laforge and Rocher Discuss the future of Groovy, Grails and Java


1. Guillaume, can you tell us a little bit about Groovy 1.8 and some of the things that are coming with that?

Guillaume Laforge: We are going to release Groovy 1.8 around the end of the year December or January, and we are working on some interesting stuff. My favorite feature for the time being is some new capabilities in terms of DSL authoring. When you are writing a DSL, you usually like to have some readable code, which pretty much sounds or reads like plain English sentences and with what we call "extended command expressions" we are really able to write plain English sentences in your DSLs that will open up very interesting possibilities in terms of the kind of DSL APIs that you can write. That’s probably one of my favorite features.

Beyond that, we are continuing adding new functional flavors around closures, like the ability to do a closure composition or also being able to use closures as parameter of annotations. There is already a project called GContracts which adds design by contract to Groovy, although the language wasn’t designed for that purpose in mind, but this syntax and new feature allows pretty amazing things. These are just a few of the new features coming up, plus some additional performance improvements and the usual minor refinements of the Groovy development kit and so on. We’re quite busy.


2. With Grails 1.4 what are some of the features that are coming up in that?

Graeme Rocher: We are working on a number of different areas. One of them is around improvements to GORM, so we’ll be adding support for database reverse engineering, migration, support for abstract inheritance trees and interfaces which we didn’t have support for before. Beyond that we are working on continuing to improve the productivity of the framework, so moving our existing class loader based reloading system to a JVM agent-based reloading allowing more types of changes without re-starting with the container. We are introducing a new resource abstraction for static resources, making it really easy to declaratively declare what JavaScript frameworks you depend on and have those all Gzipped and cache optimized and e-tagged as part of the framework. That will be a nice feature as well that plug-in authors can take advantage of. There is quite a bit of stuff coming up.


3. The development of Groovy and Grails seems very closely intertwined. How is the next version of Grails able to take advantage of some of the advances that are coming up in the next version of Groovy?

Graeme Rocher: We are definitely interested in some of the work that’s happening around command expressions and how those can improve our DSLs that we have in Grails expressing things like constraints, URL mappings and it opens up a whole range of new possibilities that we’re pretty excited about. We are continuing providing feedback to the Groovy team on what things we need next and it’s a very close working relationship between the projects.


4. For the Groovy language, how are the features for different releases chosen? In addition to the Grails needs, what other considerations come in for choosing things?

Guillaume Laforge: For different versions we’ve had some long time wishes to add this or that feature - "I think it’s time to add that stuff to the language." Sometimes some of features coming up on the roadmap are actually contributions that can come out of the blue. For instance, in Groovy 1.7 when we added power assertions, which is a nice way of showing how your assert is being evaluated, showing each sub-expression values, etc. This was something which was part of the Spock Testing Framework and we thought "Wow, that’s cool! We’d like to have that in Groovy."

It kind of came up not out of the blue, but that wasn’t really something we had thought about that someone contributes back to Groovy. Another example for even older versions of Groovy, like the ExpandoMetaClass concept, that was something that Graeme worked on inside Grails and that we migrated back and merged back into Groovy. There are certain things that are coming from other contributions, from other projects, some long time ideas that we had of things we’d like to see or features that we liked in other languages that we wanted to borrow. So it’s a bit of a mix of all that, basically.

Obviously, our users are also the ones triggering some features to be integrated into Groovy, so it’s a bit of a mix of all these things together.


5. For Grails, what are the considerations you are going through choosing future features for Grails and features developments, like with 1.4 and beyond?

Graeme Rocher: It’s very community-driven, so we have a lot of folks using Grails; we have a buzz in community mailing us. We receive over 100 emails a day from the community. There is this continuous feedback loop between the Grails team and the community and there is a great demand for things like management of static resources within the framework. So that’s driving the need for static resource handling in 1.4. Prior to that, things like a standardized security framework were needed within Grails and for that we developed Spring Security and Spring Security plug-ins.

There is a lot of innovation happening in the plug-in ecosystem and new best practices emerge from there and then we tend to embrace the most popular best practices within the core framework and make those kind of standard. It’s not just a matter of us framework developers introducing things that we think people should like, it’s more a matter of people doing experimentation within the community, something emerging as a plug-in and then we would take that plug-in, which is maybe a great concept to begin with, into a more solid form to be integrated into the framework.

Guillaume Laforge: There are also trends in our ecosystem, in our world like cloud computing or the NoSQL movement that also trigger some innovation on our side from our projects.

Graeme Rocher: NoSQL is a great example.


6. Speaking of Cloud, SpringSource recently announced the Code2Cloud. How do Groovy and Grails fit into that?

Graeme Rocher: Code2Cloud will support Groovy and Grails applications as well, and the whole Code2Cloud integration is via our STS Tool Suite, which supports the building of Groovy and Grails applications. All of the hooks from the IDE into deployment to the Cloud will support Grails applications as well, so we are pretty excited about that. All the upcoming Cloud initiatives from SpringSource and VMware are going to support Grails; VMforce will be able to run your Grails applications on the VMforce infrastructure. Every Cloud consideration that we have up and coming is going to support well Spring and Grails applications.


7. Spring Roo was inspired a lot by the Grails framework and the way that it approaches things. How do the Roo and Grails teams interact and what are some of the challenges that the Roo team faces trying to build Grails-like features when they don’t have something like Groovy, when they have Java instead?

Graeme Rocher: The Grails and the Roo teams work very closely with the Spring core team to define features that both projects need from Spring core to function. We also involved collaboratively in developing new features. In fact, both projects will likely in the future borrow significantly from each other. For example, the Spring Roo shell is something we are looking at using in Grails in the future. There will be ongoing collaboration between both projects. In terms of the challenges that the Roo team faces, it’s probably a question best left to the Roo team, but it’s a lot more challenging to add those kind of dynamic features to a statically typed language.

Some features are not possible, some of the DSLs, but luckily, SpringSource are also behind AspectJ and the Roo team are doing some pretty amazing stuff with AspectJ to make the lives of Java developers easy. But we must remember they are very different tools. Grails has a runtime component whereas Roo is a development time tool, so Roo applications and the Roo shell generate all the code but at runtime your application is just a static Spring application while Grails has a runtime environment and a plug-in model that exists, both at build time and runtime. Architecturally they are very different.


8. Can you explain a little more about the GORM changes which are coming with Grails 1.4 including GemFire and Redis?

Graeme Rocher: Sure. There is a lot of interest around NoSQL data stores within the Grails community. We are working with a number of different vendors within the Spring Data project to provide easy access to those stores via Spring and Grails applications. I’m actively involved in that project and I’m building the GORM interface onto the high level mapping infrastructure on top of the lower level Spring Template APIs to interact with these data stores. The key thing with these data stores is you want to be able to access them with a nice high level API but not take away the ability to interact with them directly and take advantage of their nicer features.

For example, if you do a mapping frame from Mongo, you want to be able to handle the common use cases using a high level DSL, like GORM, but you also want to be able to allow dropping down a layer to invoke your own MapReduce functions. We are having to go through a process of discovery to find out what is the best approach for each one and the first one we really got working really well is Redis. GORM for Redis was released about a month ago and it basically used models GORM entities into Redis hashes and querying is done by set arithmetic in Redis and it will build all your indices for you.

But if you want to drop down to the lower Redis level you have complete access to the underlying Redis data store, so you can build your own indices, do your own set arithmetic. But if you just want some of the basic querying functionality at high level, that’s all handled for you and works really well. Same GORM API, same features direct finders criteria, name queries, same features GORM developers have come to expect from GORM for Hibernate. Then at the conference we announced another implementation which is GORM for GemFire. NoSQL data stores are often touted as a solution to scalability problems.

GemFire is something that’s been solving scalability problems for years before the NoSQL term was even coined. It is essentially a distributed partition key value store with transactional right behind relational database, if you want to. It supports partitioning and continuous querying, grid computing, MapReduce - a whole bunch of features that people are not necessarily aware of. It’s really powerful and it has a complete queuing API as well. So we have taken advantage of that in GORM, so you can position your GORM entities into a GemFire data store and you can execute direct finders, criteria queries.

And we have a special support for a great feature in GemFire called continuous queries where you can register a continuous query and get events coming back and act on those events as data is being updated in your data store. It’s pretty exciting stuff. We actually have a third implementation which is complete as well, which operates against the ultimate data store, which is concurrent hash map. It’s the original key value data store, right. But it’s great for testing So you can write the same logic that you write against Redis or GemFire, but when you run it in your tests you can run it against concurrent hash map. In the future we’ll be focusing on other data stores as Mongo, Cassandra, that’s all coming on the horizon.


9. How does this relate to the Spring Data project which seems to be doing similar work for the Spring Framework?

Graeme Rocher: The projects are linked, we are building on top of the Spring Data project and in the same way that Grails architecturally builds on top of Spring, we’re building GORM for Redis, GORM for GemFire, etc, on top of Spring Data. They wouldn’t exist without each other.


10. It’s been a very long time since Java 6 was released and the Java 7 development process has stretched out much longer than most observers expected. This has led to the general impression that the Java language is stagnating. How has that affected uptake of other JVM languages such as Groovy?

Guillaume Laforge: What’s nice with open source projects like Groovy is that we can move at our own pace. Since day one, since 2003 already we’ve had closures, we had properties, we had many things which are scheduled or not even scheduled for JDK7 or JDK8. That’s the kind of features we’ve had in Groovy for a very long if not since day one. Obviously you get a chance to innovate a little more than with a bigger past. We always benefit from the novelties that are added to newer versions of Java, like when Java 5 came up we added things like annotations and generics and static imports and so on.

We’ll continue with that trend and add support and not just support but going further and improving the use of new APIs, new constructs, etc. If ever lambdas or closures or whatever they are called come, we’ll definitely they interoperate with them, with Groovy closures. We are building also on the shoulders of that giant that Java EE is but continue on innovating around the APIs, around the language features and so on.


11. One of the features we just talked about which is supposed to be very helpful for JVM languages is InvokeDynamic. What does InvokeDynamic mean for Groovy?

Guillaume Laforge: InvokeDynamic is interesting because it will allow us first of all to remove some code that we had in our code base to mimic basically InvokeDynamic. So, it’s going to be also nice in terms of code base to make things a bit more Lean and so on. Also it should speed up some of the dynamic method invocations - that’s also a nice benefit because we’ll be able to benefit from that to get a bit faster method invocation. It’s very interesting for dynamic languages obviously, but the main purpose of that new byte code instructions and all the new APIs which will be part of Java.lang.dyn - some new package.

We’re still waiting on these things to become a bit more stable, things have changed quite a lot over the past few months. Things are stabilizing, so it’s a good thing and we’ll definitely be ready when JDK 7 will arrive. We’ll see.


12. How has the Grails plug-in ecosystem helped to drive the adoption and success of Grails?

Graeme Rocher: The plug-in ecosystem is really one of the major success stories of Grails. From the beginning we put a real structure on the plug-in API and have maintained compatibility with it across Grails versions and that’s allowed the plug-in ecosystem to really flourish and allowed our community to make contributions and let the platform evolve, even when there isn’t another major version for another year or so. Even if we have Grails 1.3.5 now, 1.4 is not going to be out until March next year. There is going to be constant innovation happening within the plug-in community and the Grails platform is advancing without the need for another major release.

That’s the real benefit that it’s brought. For example, over the last few months we’ve released a GORM for Redis, GORM for GemFire - all these are plug-ins working with Grails 1.3.5.We are about to release a Flex plug-in for Grails to integrate Grails and Flex applications allowing you to develop with Grails at the backend and Flex on the frontend. We released a suite of Spring Security plug-ins where we have a core Spring Security plug-in and pluggable extensible modules for having things like OAuth and OpenID and Facebook integration all with zero configuration overhead.

There is a fantastic Spring Security UI plug-in where you can just install it and get a complete UI to manage your users and roles and permissions and so on. So we’ve been evolving and advancing the platform even without releasing new major revisions which is great, because the community can see advances being made every day. We have 499 plug-ins, we’re about to hit number 500 and there are just so many of these things all the way from complete CMS systems like the Weceem plug-in (if you want a CMS you say install plug-in Weceem, you got yourself a CMS system) to much trivial plug-ins but that add real value.

You mentioned the Google Analytics plug-in which is actually quite a trivial plug-in, but it’s just so easy that you can say "Install plug-in Google Analytics," add one tag and you’ve got it working rather than having to work it out from the various Google documentation APIs. There is such a variety of them and the community continues to innovate and it’s an exciting area.


13. How has building Grails on top of Groovy helped developer productivity with Grails?

Graeme Rocher: A large portion of the productivity benefits of Grails is at the language level. Groovy is a fantastically productive language. You are talking about the 40-50% reduction in the lines of code and you compare the equivalent in Groovy to the equivalent in Java, just that less lines of code it means less lines to maintain. And the fact that we can take your application and say "This is my code. This is your application code; now let’s enhance that with all sorts of new features without you having to do anything".

That’s through the use of meta-programming and mix-ins and that’s just a huge win, not to mention the DSLs, the URL mapping DSL, the constraints DSL. There are just so many DSLs for targeting specific areas like validation and so on. Grails wouldn’t exist without Groovy, naturally.


14. Thank you very much.

Graeme Rocher: With pleasure.

Guillaume Laforge: Thank you.

Dec 03, 2010