I can't claim that I've converted anybody from a Java to Groovy shop, or even put Groovy into wide use, but I have found some reasonable ways to get approval of Groovy code in an "enterprise" environment.
1. Fix a particularly bad pain point.
Most people interested in Groovy are painfully aware of the places that Java breaks down. Much of the time, these same areas are simple and elegant in Groovy. However, you're not going to sell Groovy in a tough environment by changing for loops to each statements.
There are a lot of places that do provide a real incentive to architects and business owners. For example:
Similar, but different classes: If you use Axis to generate classes for similar but separate schemas, duck typing can save you tons of mapping code. Rather than copying and pasting your mapper to a new class and changing all of your imports, you can make your mapper a Groovy class and remove the strongly typed parameters when possible.
Validation code: If you have a large amount of validation code that checks for nulls and/or empty strings over and over you can save a ton of time by using both Groovy Truth and null safe operators
Java
if (person != null && person.getFirstName() != null &&
person.getFirstname().trim().length() > 0) {
}
Groovy
if (person?.firstName) {
}
Imagine these chunks of code replaced over and over again in your code. This is a very real time savings.
An important point here is that the Groovy code can be isolated from other layers of code. That allows skittish architects or tentative tech leads to feel safer about making the changes.
2. Testing
Testing is the most frequent suggestion I've heard for introducing Groovy to a new environment. It's a good idea. You're not touching production code so you aren't introducing new jars to your package or risking your product with a new technology. It also allows you to learn and showcase Groovy's advantages over Java.
Unfortunately for me, this has seldom proven to be feasible. Many times you can be in an environment where the build is not within your control and thus the execution of the unit tests is out of your control as well.
If that's the case then you are back to item #1, fixing a particularly bad pain point. This may fit very well as often times tests are repetitive and verbose. Groovy makes splitting out the common code easier with features such as closures and currying.
If you do have control over how your tests are executed, by all means start using Groovy for them. What are you waiting for?
3. Scripting
Groovy is often described as a scripting language. It is really very much more, but if you’re writing scripts anyway, why not use Groovy? With AntBuilder you can do anything that Ant can, but without all of the XML. You can also easily execute items in the shell and capture output. As a somewhat random example, here’s a simple script that goes through all log files in a directory, line by line and prints the faults.
def fileDir = "logs" as File
def xmlSlurper = new XmlSlurper()
fileDir.eachFileMatch(~/.*\.log/) { log ->
log.eachLine { xml ->
def rootNode = xmlSlurper.parseText(xml)
println rootNode.name
if (rootNode.Body.Fault) {
println rootNode.Body.Fault.Code.Value
}
}
}
Or one to grab SVN properties and put them into a map.
def props = [:]
"svn info".execute().text.splitEachLine(":"){props[it[0]] = it[1]}
println props
println props["Revision"]
There are certainly other tools that can do these things, but if you’re looking for a way to get Groovy started at your company, this may be it. You never know. If it becomes popular enough as a scripting alternative it may spark more interest in the language in general.
4. Gradle
The last item I have fits only certain scenarios, but it’s worth mentioning it since it’s something in which I’ve personally found value.
In my perfect world, I would be using Gradle to build all of my projects, but again we’re in an inflexible enterprise environment right now. For those stuck with unwieldy enterprise builds, Gradle can save you some pain even if you don’t use it for your build system.
I’m not going to get too in depth on Gradle in this post, so let’s just assume that you have the basic gist of what it is. Due to the fact that Gradle easily imports builds from Ant and Maven, you can use it to tweak your existing build.
For an Ant build, you can use
ant.importBuild 'build.xml'
That’s pretty much it. Now all of your Ant targets are available in Gradle. You can manipulate them in ways that are difficult or impossible in Ant. Plus, it won’t affect your enterprise build so you can experiment at your leisure. I’ll save some of the details of how I’ve used this for a future post. Depending on how much pain you save in your local environment, you may be able to make a strong case for using Gradle by explaining the saved time/effort.
I’m sure there are plenty of other ways you can get some Groovy into your environment. The main point is that once you find an area to do this, you have something to point to when bringing up Groovy as a solution to other problems. With that ammo, you may be able to convince those that were previously skeptical.
Posts
