BT

Guillaume Laforge and Graeme Rocher on Groovy 1.7 and Grails 1.2
Recorded at:

Interview with Guillaume Laforge and Graeme Rocher by Ryan Slobojan on Dec 10, 2009 |
20:43

Bio Guillaume Laforge is the Groovy Project Manager. He is also a software architect and Open Source consultant, working for OCTO Technology. Graeme Rocher is the project lead, co-founder of Grails and is a member of JSR-241. He has written the "Definitive Guide to Grails", founded G2One and was CTO of SkillsMatter. He is a speaker at JavaOne, JavaPolis, NoFluffJustStuff, JAOO, Sun TechDays.

SpringOne 2GX is an annual event; it includes a technical exploration of the Spring ecosystem along with the latest developments in the Groovy/Grails space. As a participant, you will have the opportunity to attend two great events at one venue. Whether you're a Spring enthusiast, Tomcat user, Groovy/Grails fan, or just interested in open source development, you'll find valuable content in sessions presented here.

   

1. My name is Ryan Slobojan and I am here with Guillaume Laforge who is the leader of the Groovy project and Graeme Rocher who is the leader of the Grails project. Can you tell us a little bit about what is going to be coming up in Groovy 1.7?

In December we are going to release the final release of Groovy 1.7, we have released our last beta of the release cycle and then we are going to have a couple of release candidates before the final release. While we work on various things, let me mention a few of the things we have added. For instance we went a bit beyond what Java 5 annotations do, in Groovy we have all deriving from the Java language and Java syntax and so on, we have got support for things like annotations, generics and so on. And for instance we wanted to be able to reuse annotations in all the places than what is currently allowed by Java; for instance add in annotations on the import statements or local variables, that kind of things. And for instance in our Grape module system, if you share a script with someone, you send a Groovy script and in that script let's say you want to invoke some REST service so you are going to need HTTP client, you can say "I want to import on Apache an http client" and then on that import you are going to add an annotation saying "Ok, I want this import to be somehow related to that JAR of HTTP client".

So that way you can say Ok, grab that jar, and use that in your script" so you can really send scripts over and easily and share them without having to create a proper project. That's one of the things we have done, what else? Well a few performance improvements here and there, what else am I forgetting? There are many more things. In Groovy 1.6 we introduced a new feature called AST transformation. The AST is the Abstract Syntax Tree in memory representation of the program you are compiling basically. It allows you to transform the kind of code we are going to generate, so for instance we have got the @Delegate annotation which will trigger a transformation to do the delegation pattern in your class. And for creating those AST transformations we had to use some internal Groovy APIs and it wasn't very friendly so we have added an AST builder which provides the kind of DSL syntax for creating AST transformations.

So, first step in 1.6, the new feature and now ease of use of creation of AST transformations. We added support for anonymous classes and nested classes just like in Java, because although we had different means of easily creating new classes and implementing interfaces and so on, in some cases it's easier to just use what we are used to do with Java basically. So although closures were also there to avoid using those constructs in some frameworks where you rely heavily on those constructs it's easier, so we even increase further the compatibility, syntax-wise with Java. And another feature that I quite like is what we call Power Asserts. So in Groovy we have an assert keyword, an assert statement that you can use to assert something is true etc, and we improved it so that when you actually assert a complex expression, with various sub-expressions, so let's say A+B=C, when the assertion is failing, you have got a nice decomposition in a tree form somehow to see the values of each part.

Usually you tend to write as many assert statements as needed now you can just combine everything in one and see how all go: "Oh, this variable A didn't contain the value expected", or something like that. So it is quite nice and it's a feature which was coming from a testing framework built for Groovy called "The Spock Framework". And we borrowed that feature into Groovy because it's quite nice for testing. And that is basically it for Groovy 1.7.

   

2. What are some of the new features that are coming in Grails 1.2?

Graeme: In Grails 1.2 the main focus is around stability and incremental improvements, but we are still introducing a number of key features, which I believe the community will appreciate. One of the main ones is dependency resolution. We have a dependency resolution DSL now built in Ivy. Previously you needed to use Maven in order to get dependency resolution. And we don't want to force Maven on unsuspecting users, so we implemented our own DSL that lets you resolve Java files.

Grails has a plug-in system so it has applications and it has plug-ins, and plug-ins might have dependencies themselves, we needed the most specific DSL for controlling not only your application dependencies but also the plug-ins that you have installed, their dependencies as well. It's a little bit different to the typical flat list of dependencies you see in for example Ivy or Maven, we have a hierarchy of dependencies where you control not only your application dependencies but also each individual plug-in dependencies so you can be able to overwrite/exclude/include and change the way dependencies are resolved. So that is pretty a key feature. Other than that we have worked on incrementally improving GORM. There are some really nice features around GORM.

GORM is the persistence layer that is built in Hibernate. So we have added things like name query support, so you can name a query and reuse it again and again, we have added more advanced finder constructs for boolean properties which make them simpler to query with boolean properties, we have also implemented some interesting things which are useful for IDE vendors, so for example working closely with the STS team, here at Spring Source we have added the ability so that the IDE can overwrite the test so you get good feedback from when running Grail tests. We have implemented a plug-in meta data generation engine we like to call it, probably but long winded but anyway it's basically the ability to bootstrap the plug-in and detect which methods and properties are added by a plug-in to Grail when during the plug-in publishing process which means that an IDE can when it detects the plug-in, can automatically discover what additional methods the plug-in ads so you get code completion and so on for plug-ins that are added. We have also added improved support for REST so you are able to now adjust the HTTP method by a form which wasn't possible before. And in general it's just a lot of incremental improvements that I think users will be keen on seeing.

Guillaume:Performance improvements, very important performance improvements.

Graeme: Yes, so there is for example GSP was one of the bottlenecks in Grails in terms of performance and we have worked pretty hard on making it a lot more performant. Some of the things we have done, for example, we have implemented a GSP pre-compiler, so instead of compiling GSPs at runtime doing deployment now it compiles them ahead of time. We have pretty much completely re-written the GSP rendering engine so that it uses dramatically less memory andg it's resulted in something like two to three times throughput when rendering a GSP page. So we are pretty pleased with the performance improvements you've seen in Grails 1.2.

   

3. Are the developments cycles of Groovy and Grails related in any way?

Guillaume:Yes, definitely. For instance when we noticed the example of performance improvements in GSPs for instance when we notice this bottleneck related to the internals of Groovy obviously since we were working closely together, is obviously a good opportunity to fix those bugs or issues in a high priority. And beyond that of course Grails' new versions use a newer version of Groovy, so we usually try to relate the versions that we release. So, Groovy 1.7 in Grails 1.2.

Graeme: I think that in the past the development cycles were a lot more tied together in terms of the feature development, this was due to the fact that at the time in the early days of Grails I was contributing quite a lot to Groovy and also to Grails and Grails needed features from Groovy which didn't exist yet and those were added and they were very complementary but Groovy is a lot more mature now, so really the synergies are more ok if we find a particular bottleneck or a particular bug, that gets fixed and goes into the next release to Groovy which goes into the next release of Grails.

Guillaume:And a few key features like expanding meta-class for doing dynamic meta-programming or having some nice DSLs for configuration or contributing back to Groovy.

Graeme: Yes, if there is a DSL that we create within Grails which is general purpose. And it tends to sometimes go back into the Groovy and the Groovy project as he mentioned. And that is actually going to happen a lot more with Spring too. For example we have a Spring configuration DSL which is part of Grails which will eventually be moving to Spring and so all the projects are benefiting from each other.

Guillaume:So that's definitely the nice aspect of working in the same company so that we can all share all the things that can be reused, have a closer relationship with our colleagues and teams and projects. Big benefit.

   

4. I have noticed that Spring Roo seams to draw a lot of ideas from Grails. Can you speak a little bit more about that?

Graeme: Sure, yes, I mean obviously we are in touch with the Rue team very often and discussing ideas and so on. Roo definitely takes a lot of influence from Grails, the main driver for Roo is that in term of a lot of conservative organizations are definitely a lot slower to adopt newer languages such as Groovy and so on. And in those kind of environments where Java is the only language and that is the standardized language that people work with, it would be a shame if those people couldn't benefit from a rapid application development framework. And that is really what Roo suit is for existing companies who are not able to use anything else other than Java. In terms of Grails obviously if you look at the Java language innovation is pretty stagnant within Java right now, and all the real language innovation is happening outside of Java. And obviously because we have built Grails with Groovy, which has features that you don't find in Java, we were able to achieve things that are pre-compiling DSLs and AST transformations and so on, to make it a very concise environment to work with, very simple.

   

5. How has the acquisition by SpringSource changed Groovy and Grails development?

Guillaume:From Groovy prospective things haven't changed much; I think that it's more around Grails that things are more significant.

Graeme: Yes, I mean the two projects are distinct in that Groovy has a lot of active contribution from both outside and inside SpringSource. Grails on the other hand is mainly SpringSource. And in terms of the relationship to the other teams, with Grails being built on top of Spring, Grails using Tomcat as the container, there is a lot of synergy between the teams, and that has been the real change, if there is a particular feature needed or a bug in it, that never happens in Spring of course, if there is, I can relate directly to the Spring team and get those issues resolved. Same with Tomcat, if there is anything in Tomcat, for example Spring has worked very hard to make Tomcat embeddable, within different programmatic API, and that has resulted in Tomcat plug-in become much more seemliness within Grails than it was before. And also in terms of being able to mould the container to the Grails environment while molding Grails to the container it has been very productive to us to be able to talk to the Tomcat team to implement various features. It extends throughout the whole company in terms of what we are doing between Grails and the Cloud Foundry team, or Grails and Spring team, or Spring security, Spring integration, Spring Flex.

   

6. You have mentioned the Cloud Foundry. I have heard discussions about grails based solutions in the Cloud. I am assuming that is the Cloud Foundry?

Graeme: Yes, Cloud Foundry is a web application that you can sign up for now, it's in beta and it basically allows you to create from blue prints a complete environment to run Grails or Spring applications on. And it's a pretty compelling environment, for example you can choose from a single typology where you just have a single server with HTTP and HTPD and TC server and MySQL or you can have a multiple typology server set-up automatically. It'll start up your environments and features scaling, low balancing, and it's a pretty awesome product and we have developed integration between Grails and Cloud Foundry which should emerge after this conference and it's never been similar to deploy Grails application, you literally go Grails install plug-in Cloud Foundry and Grails Cloud Foundry deploy a new application is running back on to Amazon EC2. At the moment Cloud Foundry is back on to Amazon EC2 but we see product being generic interface onto various cloud solutions. We are back working closely with the VMware team to further its use across the VMware suit of products.

   

7. Can you tell us a little bit more about some of the recent developments in Eclipse based tool support for both Groovy and Grails?

Guillaume:Yes, historically we had a Groovy plug-in for Eclipse just developed part time by a few committers, so although there were some very nice features, it's never been to a standard of quality that we expected and so we really needed resources and talented guys working on that. Fortunately the Eclipse developers the Eclipse team at SpringSource worked to bring some new features at very rapid pace. Now editing Groovy code, code completion and all that stuff is available. And compared to what we had before it's a huge progress. And there is also the Grails support that is coming pretty soon.

Graeme: Yes, within STS which is the SpringSource Tool Suit, there is a coming Grails support, the first version of that was previewed here at SpringOne. . It's a pretty exciting time because comparing with the work that is happening on the Groovy Eclipse plug-in which is providing a very solid environment for developing Groovy code, solid base absolutely because fundamentally you need to get the language, the basic editor of Groovy code working first. And that is really what the SpringSource team has been working on. They have done a fantastic job in getting it very solid the compiler, which is based on JDT, is very solid and supports basic refactoring and code completion. They have done a great job. So the next part is to extend that work to work with Grails and that work is happening inside SDS because obviously Grails is based on Spring and all the SDS tooling and it applies to Grails as well. Soon you will be able to download an SDS distribution and then install the Groovy Grails support and have a complete Groovy-Grails environment within Eclipse which up until now only in IntelliJ we were having a little bit of support. It's great to see the landscape of Eclipse tooling opening up.

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT