This month's StL JUG features Matt Taylor speaking on TDD with Groovy (tonight!).
Like last month's post on Clojure, I'll play law professor, and try my hand at making some arguments that Groovy is the JVM-based language you should learn (if you can only pick one). Like last time, I'm treating this as an exercise, though this is easy, as I am a Groovy fan.
Grails
Long ago, I would say that the first reason for Groovy was its learning curve. That is still important (see below), but my new first reason is: Grails.
I imagine most readers are familiar with Grails: a Rails-influenced web framework that stands on the shoulders of giants -- namely, Hibernate and Spring. The reason I put this item up front and center is that you can make money with it. There are real jobs to be had here, folks. This is a powerful framework with plenty of momentum.
Griffon, GORM, Gradle, Gant, ...
In addition to Grails, there are several other projects that are intimately related to the Java platform. e.g. Griffon brings Grails-like conventions to Swing apps. Straight from Grails, GORM is a DSL for Hibernate mappings. Gradle is a next-gen build system that stands on top of Ant and Maven, without all that nasty XML. Gant is somewhat similar, used by Grails.
The upshot is that the Groovy community is vibrant and doing many different things: surely something will be useful to your project.
The Language
Up to this point, I haven't written about the language itself. IMO, Groovy seems familiar to Java, but with all of the ceremony stripped away. Tremendous amounts of boilerplate are removed: getters/setters are gone; access modifiers have reasonable defaults; regular expressions are trivially easy; and so on.
But there's more: dynamic typing, closures, the Meta-Object Protocol, and other features provide a rich feature-set that is quite different from a merely trimmed Java.
Tools and Testing
Scott Davis has written an excellent book with the subtitle "Greasing the Wheels of Java". That is spot-on. For XML, web services, scripting Java libraries, etc, Groovy is amazingly useful and effective.
One of these aspects is testing (this is where Matt's talk applies). Groovy has tremendous support for unit-tests, including mocks and stubs. The dynamic nature of the language offers a lot of options. Come on out to the talk to see more on this item.
A Gentle Learning Curve, With Growth
If you know Java, Groovy is extremely easy to learn: in fact, almost all Java will run as Groovy. The curve actually goes downhill (in a good, effortless way).
Now, you may dismiss this. As a reader of this and other fine blogs, you may be confident that you can learn any language, thanks. I'm sure you can. The usefulness of the learning curve is that your work (e.g. a utility) is far more likely to be used by other Java developers. In a team environment, that's important. Groovy is unmatched in this regard: it promotes social computing.
That is, if you want it to do so. If you want to do something wild, Groovy allows you to grow into that as well. In this spirit, it is reminiscent of Python: the curve is always reasonable but seems to climb forever. As mentioned, the dynamic nature of the language will definitely, quickly, take you to places that you haven't been using only Java.
The Upshot
I realize there are no code samples in this post. I apologize. Again, this is a quick list of 'arguments' for learning Groovy as your next language on the JVM. There is a ton of material out there, both in free documentation and in books.
(Full disclosure, some of the following authors are friends.)
For Groovy books, start with either Programming Groovy or Groovy Recipes. For Grails books, pick up either Grails: A Quick-Start Guide or the ultimate reference, The Definitive Guide to Grails.
Either way, give Groovy a shot, or come on out to the StL JUG. It is time well-spent.
Great post, and I agree with your assessment of Groovy and Grails. I look forward to more of your writing.
ReplyDeleteI agree that if you are to learn just one JVM language, then Groovy is a very natural choice. However, if you already know Java, then perhaps the similarity of Groovy to Java doesn't give as much bang for the buck as other options. My Scala bias is showing here, but someone already comfortable with Java will be pushed farther out of their comfort zone, and learn more, by diving into Scala or Clojure than Groovy.
ReplyDeleteI think its antithetical to make a claim for a dynamic language based on a code generation framework like Grails.
ReplyDeleteEven Java programmers know what happens when you build a system built on massive codegen of supposedly "trivial" artifacts.
I would like to see an argument for Groovy free of Grails.
No way I'll tie myself to a language to get at a bait and switch framework like rails.
"I think its antithetical to make a claim for a dynamic language based on a code generation framework like Grails"????
ReplyDeleteI think you should try using Grails a bit more and then you will realize how incorrect your statement is. Grails is not a code generation framework. Are you equating code generation to scaffolding?
Sry I forgot that scaffolding is not codegen.
ReplyDeleteThanks for the notes everyone...
ReplyDelete@Morgan There are certainly drawbacks to any language. The intent here was to state the case for X as best I could. I hope to write about Scala or jRuby later in the summer as time permits.
@Overtheline To see an argument free of Grails, simply omit the first item in this list ;-) I think the case for Groovy would still stand without the Grails item.
Even if my 'case' doesn't stand, that's fine, but Groovy by itself (and its libraries) definitely is worthy of study, even without Grails.
I've now been using Grails on my primary project for about 16 months (not just toying with it--this is at my "real job" on a large project for one of the 50 largest companies in America). My appreciation of it has continued to grow, and I have complete confidence in it as an appropriate choice for 95%+ of business applications.
ReplyDeleteScaffolding is NOT a primary benefit of Grails. It enables cool 5 minute demos, but the real world benefits of Grails are much deeper. There are simplified (auto-wired) conventions, built in tools, or plugins for nearly every aspect of web development. This enables a massive increase in productivity by enabling and encouraging clean solutions that don't re-invent the wheel. Perhaps even more importantly, this keeps the code lean, which is very important for long-term maintenance, refactoring, and preventing "sleeper defects" that tend to hide in bloated code.
I needed to add caching for some web service calls to improve performance: 11 lines of code (entirely declarative).
To meet a versioning requirement (lock, copy as new revision), I needed to implement deep cloning of a persistent domain tree with child associations (mostly collections) five levels deep, with multiple branches, touching about 30 persistent objects. Some needed to be copied by reference (for example, a createdByUser association), and some cloned as new (recursively deep cloned). My implementation is completely generic and won't require changes if the domain model is changed. Pass the method a domain object instance, it hands you back a copy with all of the children copied and properly attached to their new parents. Then you call .save(), and all of the new ids are generated and your database has been updated. This one is a testament to the power of Grails metaprogramming with GORM and Groovy: 22 lines of code.
I needed to create a utility application for mocking a third-party SSO module to enable logins on staging/demo servers. It validates user inputs, makes an AJAX request to the target app with modified request headers to initiate a browser session, and launches it with the intended user now logged in. It uses a proper MVC architecture, the layout is configured with SiteMesh, it has configuration/build management and versioning, URL mapping/redirection to keep it friendly, and log4j integrated and configured. From creating the project to building the WAR file, it took 4 hours.
Point proven?