The following bit comes from Forever Precious, a multi-user collaborative wedding website service.

Grails, the groovy web framework has some really nice features - we feel GORM in particular leads to more rapid prototyping and cleaner code. However, at least as far as eclipse goes, raw Java is still much better supported than Groovy in terms of IDEs and refactoring (IDEA Groovy support is more advanced - but we use Eclipse here at foreverprecio.us). So we found ourselves in the position of wanting to use Java for a large portion of our code base, but also wanting to take advantage of the dynamic language capabilities of Groovy and the fantastic features of Grails.

We started with a plain vanilla Grails app, but rather than launch the application via ‘grails run-app’ or ‘grails deploy’ we created our own GrailsApplication instance and imported the precompiled classes from Grails. This provided us with a number of advantages. Groovy classes compile to plain old Java byte code, which means that precompiled Grails classes can be very easily referenced from Standard Java classes.

It is a well known fact that Grails follows the Convention over Configuration paradigm, but it surely is not (as Jason Rudolph puts it) Convention instead of Configuration. If you really need to tweak Grails in a way that is not provided by default you can certainly do it. Being able to create your own bootstrap sequence with a custom GrailsApplication class is a testament of that.

We started off rapidly prototyping most code in Groovy and Grails, then piece by piece ported the less dynamic portions to IDE refactorable Java. In a way the original Groovy and Grails code not only helped us get up and running quickly but also served as spec for the application. Grails code and Java code are malleable in different ways - Eclipse provides excellent refactorability for Java, but not yet for Groovy. However in a standard app, this is sometimes mitigated by the reams of XML (or even annotations) needed to configure the application. In Grails convention over configuration and the dynamic nature of Groovy provided malleability at a higher level than the refactorability of Java and served really well for rapid prototyping. Our Java / Groovy bridge - the Groovy Access Object and the syntactic similarities between the languages meant that we were able to reuse much when converting parts from Groovy to Java.

Another reason for Grails to be a good choice: rapid prototyping of a web application. You are free to reuse the prototype or mix in as much Java code as required. Groovy works as a glue through all of Grails’ artifacts and it surely gives you productivity gains, but if you need Java for an specific constraint (tool support is a valid one) then Grails will be happy to oblige, it will not force you to use Groovy as the sole language.

Tags: Grails