by Sibers CTO Andrey Gavrilov
As for the language itself, Groovy is essentially a script language using JVM as a virtual machine, which also supports scripts for Java applications. Due to JVM, it can work directly with Java classes using its syntax and script features and can even add dynamic features to the existing Java classes.
Writing a script for Java is not a problem as Java realizations can be written in many script languages (Jython, JRuby, Rhino, etc.), but Groovy as an alternative to writing a Java bite code is interesting enough. Groovy supports all the main features of script languages (such as iterators, closures, treating all entities as objects, etc.) at the same time having a sound Java-like syntax. (It’s to place some blame on Ruby for its heavy Perl and Python inheritance with its meaningful standoffs.)
Frankly speaking, I don’t think using a script language gives any advantage in the code capacity comparing to modern Java (setting apart Perl and corresponding Ruby syntax as their small capacity is achieved through decreased readability). However in certain respects Groovy gives serious benefits. For instance, when creating beans in Groovy the fields are public by default and need neither getters nor setters. However, you can always redefine the default getters/setters if necessary. It causes huge economy of code for frameworks working on beans.
The language is “mature” enough (in version 1.0), but decent documentation is still scanty. Groovy is supported in Eclipse, NetBeans (project coyote) and Idea, but the plugins are raw yet and fail to support many handy features.
Now to Grails. It’s obvious that Grails stands for Rails ideas realized in Groovy. The same MVC, modules generated from command-line, scaffolding, etc. The difference shows itself when you input “groovy war” as you program transfers into a correct war archive built on Spring + Hibernate. It’s impossible to demonstrate all the power of both, but some things can be easily added to Grails from outside as Spring allows it quite easily.
Actually, the opportunity to write in Spring without those tiresome beans (see above) and Kb of XML is quite inspiring. Add to this the advantages of using all existing Java realizations (cf. BMP having 1.5 realizations in .Net, about 15 in Java and nothing in any other languages).
An essential point is integration with IDE. While creating a site, you automatically have an Eclipse project generated, which can be further imported to both NetBeans and Idea. Combination of creating program elements from command line and working in IDE, though, doesn’t seem comfortable and the plugins themselves are a bit raw (e.g., I faced a situation when Eclipse defined a syntax error in Grails itself). Let’s wait and see more specialized plugins for Grails manage to perform all the command line operations from the environment.
All in all, Grails creates a very grave impression despite some drawbacks mentioned (the current version is 0.31). It’s stable enough to begin using it right now. It’s also worth mentioning such a feature to come as Laszlo on Grails, which is now at its initial stages of development. This integration is supposed to provide a very serious level of RIA development.