Groovy is the New J: What is Groovy Used For?
Java. JBoss. JEE. It seems the uppercase letter “J”, much like the lowercase letter “I”, has dominated the scene for quite a while in the web application world.
That’s changing. G is the new J. G is for Groovy. And it is groovy. Why? JEE developers got tired of writing the same voluminous and repetitive code. Enter Groovy. Groovy on Grails, with GORM, that is. A better, faster way of developing web applications that truly enables developers to focus on application logic, not plumbing code. A syntax that enables developers the flexibility to sling scripting-like code with the power of Java behind it. Inspired by Ruby on Rails, Groovy & Grails was built to boost Java developers’ productivity — and it has largely succeeded.
Why G is Better Than J
Nobody argues that J(2)EE was and is overly complex. Even implementing some common functions within the Java language itself are complex, and require the same repetitive lines of code to implement basic functionality. Groovy is an abstraction on top of Java, and the Grails framework is an abstraction on top of Spring and Hibernate.
Let’s take a look at the differences between Groovy and Java.
Domain vs. General Purpose Programming Language
Groovy is a domain specific language. It is built primarily for the purpose of building Java-based applications – quickly, cleanly, efficiently.
Java, on the other hand, which is widely used for creating web applications, can be used to build serial-level device drivers, fat-client window-based applications, or native mobile apps. Java is a general purpose programming language that can easily be used for a broad spectrum of application development.
Down With Boilerplate
One of the basics of Groovy is that eight commonly used packages are imported by default. This relieves developers from the drudgery of explicitly importing packages like java.lang and java.util. It also cleans up the code a little bit, cutting down a few LOCs.
What does Groovy have that Java doesn’t?
Just a few of many interesting things:
- Closures
- Dynamic typing: can be both a blessing and a curse
- Native syntax for collections AND regular expressions
- Switch statement that can handle switching on ANY type of value
- Named parameter passing: makes for clean, self documenting code:
def myVehicleClass = new Car(type:”sedan”, make:”Volkswagen”, model:”Jetta”, fuel:”diesel”) - “Safe navigation”: no more null checking! myObject?.objectProperty?.getAttribute() will not throw NPE if either myObject or myObject.objectProperty is null
Cleaner Code
Check out the difference between Java and Groovy in creating and printing out a map.
Here is the typical Java code:
Map<String, String> stateMap = new HashMap();stateMap.put("NEW", "This workflow has not yet begun.”);stateMap.put("PAUSE", "This workflow is stopped temporarily waiting on an approval.");stateMap.put("COMPLETE", "This workflow has been completed.");stateMap.put("ERROR", "This workflow is in an error state and needs to be addressed by Support.");for (Map.Entry<String, String> entry : stateMap.entrySet()){System.out.println(entry.getKey() + ": " + entry.getValue());}In Groovy, that same code would look like (your eyes will say “aaaaahhhh”):
def stateMap = ["NEW": "This workflow has not yet begun.”,"PAUSE": "This workflow is stopped temporarily waiting on an approval.","COMPLETE": "This workflow has been completed.","ERROR", "This workflow is in an error state and needs to be addressed by Support."]stateMap.each {key, value ->println “$key: $value”}
Grails
Grails is a platform inspired by Rails, which provides a level of abstraction above Spring and Hibernate. It boasts a rich offering of plugins to do just about anything you can think of — including NoSQL, caching, security, and messaging, just to name a paltry few.
It has GORM, the object-relational mapper built on top of Hibernate. It supports Spring’s Web Flow, making it easier to work with complex workflows. Scaffolding enables rapid application development by providing developers with a base set of code from which to start.
So for instance, if you want to create the database schema for your new application, you don’t need to write a lick of SQL to create any tables. Grails does it all for you via the domain model. You simply code up your domain objects (much like POJOs), and when you start the application, Grails will, according to whatever database settings you have configured, either (drop and) create the database from scratch, or update it according to whatever deltas it finds between the existing table structures and the domain objects mapped to them. (For stored procedures, however, you are on your own. It’s not that smart.)
For each domain object, Grails can also create a scaffold application that allows you to perform the basic CRUD operations on it. This is especially helpful in whipping together quick demos and proving out the domain model you’ve designed.
Unit Testing is supported in Grails, and provides very basic functionality — not much more than the framework of the unit test. Integration testing, however, is very powerful in Grails. Grails supports the creation and running of integration tests which loads the entire Grails environment at test time, enabling the use of dynamic finders and full database functionality.
What’s the catch?
Here at RTS, we have been able to drastically cut our time-to-market using Groovy and Grails for new application development. One key note is performance of database queries. Most applications are built on top of very simple queries, which Grails handles suitably.
But for those situations where you have a complex query, one which might require joins or scan large amounts of data: you’re better off using a stored function (or procedure). Grails will give you the 80%, but for the troublesome 20%, be sure you have someone on your team who can author procedural SQL on your database.