A few weeks back I went to a local launch party for Groovy, a FOSS dynamic programming language written in Java. The language will be familiar to Java programmers. It was written that way. In fact, you can write straight strongly-typed Java code using the Groovy environment, so you can use as little or as much of the dynamically typed features as you like. The advantage you gain from using the dynamic typing features is you get brevity of code. As I’ve said before, it’s easier for the developer to express their intent in code without it getting lost in a bunch of types. The code that you write is more powerful. You don’t have to tell it every single step you want it to do. It can figure some of it out for you. This saves you time, and helps you write code that’s easier to read.
It enables you to either run code through an interpreter or compile Groovy code into modules that can be packed in JAR files and run on a JVM.
One of the exciting parts of Groovy is Grails–the Rails framework for Groovy. I’m not that familiar with the Java web frameworks that are out there. What was shown to me showed that Grails is compatible with Hibernate, and Spring. The presenter pointed out that as of the first final release of Grails, it’s not compatible with Struts. From what I heard at the meeting this is a major minus, because lots of places use this web framework.
Grails offers pretty much the same ease with which Ruby on Rails (RoR) creates web sites, but it does it in a way that Java developers would be familiar with. For one thing, rather than defining the data model in the database first, as with Ruby, you define the data model in Groovy code, and Grails sets up the database tables. All the same, Grails sets up default web views for you, just as RoR does.
As with RoR, it uses convention over configuration. All files that make up a Grails site go in certain proscribed directories. This goes for any Hibernate and Spring files that will be used in a Grails web app. as well. It’s not as if it picks a directory on a certain hard drive and sets it in stone. You can set up your own web app. directory. Once you set up the main directory, every folder under it is proscribed by the framework.
On the minus side it doesn’t make it too easy to set up your own domain-specific language (DSL). Groovy has some nice built-in DSLs for dealing with creating a web interface, opening files, executing shell commands, and dealing with XML, among other things (that’s just what I saw in a quick demo), but adding methods to standard types is clumsy. This is kind of a disappointment for those who like the ability to define their own DSL in a dynamic language. It works the same way as “extension methods” will in the Orcas release of .Net. What they do is add the same method to every class that is used within a certain scope. This is unfortunate because you may want to add a method to just one standard type, but you’ll end up adding the method to every type that’s used within the defined scope. I guess it’s a compromise. The way the presenter for Groovy explained it is that since Groovy, and Java for that matter, operates in a multi-threaded environment, this was the only way it was possible. He explained that Ruby does not have this problem because each instance of a web application runs in its own thread, thereby making it easier to add methods to standard types. I’m not sure why this makes a difference, but I’ll take his word for it.
Overall I enjoyed the presentation. I’m happy to see that dynamic languages are “storming another beach head” in the programming world.
aboutGroovy is an educational site for Groovy. You can view tutorials, and preview some of the Groovy and Grails books that are out there.