Joe Kueser's Blog » programming http://joe.kueser.com Another Geek Finding His Place on the Web Sat, 01 Oct 2011 23:01:53 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 What Makes Groovy So…Groovy? http://joe.kueser.com/2007/10/what-makes-groovy-sogroovy/ http://joe.kueser.com/2007/10/what-makes-groovy-sogroovy/#comments Sun, 07 Oct 2007 04:04:34 +0000 Joe Kueser http://joe.kueser.com/?p=7 Ever since attending the No Fluff Just Stuff symposium last month, I've been digging into Groovy, and have frankly been blown away. As I watched the presentations, and as I have done my own research, I have been blown away by Groovy's power. I'm convinced. I have to use Groovy. It's that good. I am, however, having a little trouble convincing others of its coolness. Maybe this will help others. Please leave your comments and let me know what you think. I wrote a blog about it. Here it goes!

As I dig deeper, I find that features of the language fall in to four basic categories:

  • Wow! That's really groovy!
  • Wow! That's really useful!
  • Hmmm...that's good to know.
  • Nice...but will I use it?

I will focus on the really useful, much of which is also very groovy, but as my boss might say, "groovy don't pay the rent." (He's kind of weird like that.)

Top 10 Grooviest Groovy Features

10 - Brevity (Less is More!)

brev∑i∑ty (br?v'?-t?) pronunciation
n.

  1. The quality or state of being brief in duration.
  2. Concise expression; terseness.

Yeah. Definitions are cool! And that pretty well sums up what Groovy gives you in terms of coding. By eliminating some of the scaffolding we normally put in our Java classes, Groovy can cut down that amount of code we have to write substantially. I'm not sure that this is typical, but I recently converted a fairly complex Java class to Groovy. The Java class had 1,800 lines of code. The Groovy equivalent was down to only 1,100 lines of code. I'm not real good with statistics, but that seems to be about a 40% reduction.

This is more of a "Wow! That's groovy!" than useful, but it certainly is nice to have. For me typing less per method means more functionality in the same amount of time. And this is with only about 1 week worth of experience. I look forward to what I can do when I learn the ins and outs of the language.

9 - Ranges

OK, fess up. How many times have you written code that looked a little something like this?

  1. for (int i = 0; i < upperBoundry; i++) {
  2.     // Do something interesting
  3. }

or tried to figure out if a number is between two other number by doing something like this:

  1. if (x > 3 &amp;&amp; x < 10) {
  2.     // Do something else
  3. }

Well, Groovy makes this easier, and it's really pretty intuitive. The range format is

[lowerBound..upperBound], [upperBound..lowerBound]or [lowerBound..<upperBound]

So can you guess what this does?

  1. [1..10].each { item ->
  2.     println item
  3. }

Yep, it prints the numbers 1 through 10. Easy, right? Ok, how do you like this?

  1. if ['a'..'z'].contains(test)

That simple little bit of code could be used to see if a letter is between 'a' and 'z'. (Note: you probably wouldn't use ranges to figure out if a character was a letter, that's just here for illustration purposes. More likely you'd use the "~", "=~", or "==~" operators, which let's you evaluate regular expressions. Make sure you check out Groovy's Regular Expression support page.)

Now falling right in to the groovy and useful category is how you can use these ranges in switch statements. Let's say, for example, that you have an insurance company that has different rates depending on the age range of the policy holder. That code might look a little something like this:

  1. switch(age) {
  2.     case 16..20 : insuranceRate = 0.05 ; break
  3.     case 21..50 : insuranceRate = 0.06 ; break
  4.     case 51..65 : insuranceRate = 0.07 ; break
  5.     default : insuranceRate = 0.10
  6. }

Ranges aren't limited to predefined goodies like numbers and letters. You could also create an array, or dates, or any other comparable objects, and use those in your range statements.

8 - GroovyBeans

Much more "groovy" than useful, but certainly does cut down substantially on the extra scaffold code you need to write, GroovyBeans are just like JavaBeans, but a lot smarter.

In Java, you might create a simple Person class with a first name, a last name, and an email address. You create the private variables for each of these, and then getters and setters for each. You do the same thing time after time...or usually let your IDE do it for you. Your code for this Person object would probably look almost exactly like this:

  1. public class Person {
  2.     private String firstName;
  3.     private String lastName;
  4.     private String emailAddress;
  5.  
  6.     public String getFirstName() {
  7.         return firstName;
  8.     }
  9.  
  10.     public void setFirstName(String firstName) {
  11.         this.firstName = firstName;
  12.     }
  13.  
  14.     public String getLastName() {
  15.         return lastName;
  16.     }
  17.  
  18.     public void setLastName(String lastName) {
  19.         this.lastName = lastName;
  20.     }
  21.  
  22.     public String getEmailAddress() {
  23.         return emailAddress;
  24.     }
  25.  
  26.     public void setEmailAddress(String emailAddress) {
  27.         this.emailAddress = emailAddress;
  28.     }
  29. }

Ho hum...how monotonous. How boring! If the IDE can generate those getters and setters for us, why can't Java? Well, because Java's not Groovy (though Groovy is Java). The Groovy equivalent of the above class skips all of that getter/setter silliness and you are left with this:

  1. class Person {
  2.     String firstName
  3.     String lastName
  4.     String emailAddress
  5. }

I know, you're saying, "but I need my getters and setters!" Don't worry sport, they're still there, at least as far as your code is concerned. How would Java call each of the methods in the Java class? Maybe...

  1. System.out.println("First Name:" + getFirstName());
  2. System.out.println("Last Name:" + getLastName());
  3. System.out.println("Email:" + getEmailAddress());

And how would Java call each of the methods in the Groovy class? Would you guess...

  1. System.out.println("First Name:" + getFirstName());
  2. System.out.println("Last Name:" + getLastName());
  3. System.out.println("Email:" + getEmailAddress());

Exactly the same. How would Groovy access each of these? Either using the property name or the getter/setter.

  1. println "First Name:" + getFirstName()
  2. println "Last Name:" + lastName
  3. println "Email Address: ${emailAddress}"

Notice the last line. This introduces something called GStrings (I'm not making this up). It's a way to include the variable values right within the screen. This same methodology is used in Maven, Ant, JSF, and other technologies, so it's nothing new. Just new to your Java code.

How do you set the values? Pretty much like you'd think:

  1. emailAddress = "sample@example.com"

7 - Expando

The Expando class is fashioned off the real-life file folders that expand to fit whatever you put inside them. These fit more into the "groovy" than "useful" category, at least on the surface, but this capability opens the door for some huge dynamic possibilities. Within your code, you can create methods as needed. Here's a trivial example that I borrowed from an excellent book, "Groovy in Action" (buy it now!)

  1. def boxer = new Expando()
  2. assert null == boxer.takeThis
  3. boxer.takeThis = 'ouch!'
  4. assert 'ouch!' == boxer.takeThis
  5. boxer.fightBack = {times -> return this.takeThis * times}
  6. assert 'ouch!ouch!ouch!' == boxer.fightBack(3)

This example shows the creation of a "boxer" Expando, and then shows that the "takeThis" method didn't exist. The "takeThis" method is then created and accessed, as is a fightBack method. This shows one use for Closures, which I'll get to later. While the use for Expando classes may not seem immediately evident, the power of the Expando enables some of Groovy's grooviest features.

6 - Grep

To most geeks, grep is a very useful UNIX command. Groovy brings this kind of power to Java. Here's another example from "Groovy in Action":

  1. beasts = {'bear','wolf','tiger','regex'}
  2. assert beasts.grep(~/..../) == ['bear','wolf']

Grep here is used to find all of the 4-letter words in the array. A full array of options, and regular expressions, are available to the grep command.

5 - Spring Integration

Spring is a very cool technology, which allows you to dynamically include classes in your classes at runtime. On the downside, Spring configuration is a pain in the butt. From the SpringFrameworks web site:

  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <beans xmlns="http://www.springframework.org/schema/beans"
  3.        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  4.        xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
  5.  
  6.   <bean id="..." class="...">
  7.     <em class="lineannotation"><span class="lineannotation"><!-- collaborators and configuration for this bean go here --></span></em>
  8.   </bean>
  9.  
  10.   <bean id="..." class="...">
  11.     <em class="lineannotation"><span class="lineannotation"><!-- collaborators and configuration for this bean go here --></span></em>
  12.   </bean>
  13.   <em class="lineannotation"><span class="lineannotation"><!-- more bean definitions go here... --></span></em>
  14.  
  15. </beans>

Using Groovy's builder classes, we are able to use Spring within Groovy without a single bit of XML configuration. (I would put an example below, but I can't find one :-) )

UPDATE:† Ok, my Spring portion was lame.† So, special thanks to Paul King for pointing me to this link.† Told you this Spring stuff was Groovy!† http://groovy.codehaus.org/Using+Spring+Factories+with+Groovy†

Speaking of builders...

4 - Builders

In Groovy, the Builder classes provide an easy way to narrow down repetitive tasks and build non-Groovy items, such as XML and HTML documents, Swing GUIs, and pretty much anything else you can think of that follows a pattern. Let's take a really simple XML example:

  1. <?xml version="1.0">
  2. <people>
  3.   <person>
  4.     <firstName>John</firstName>
  5.     <lastName>Doe</lastName>
  6.     <emailAddress>john.doe@example.com</emailAddress>
  7.   </person>
  8.   <person>
  9.     <firstName>George</firstName>
  10.     <lastName>Bush</lastName>
  11.     <emailAddress>prez@whitehouse.gov</emailAddress>
  12.   </person>
  13. </people>

In Java in order to create such a document, you'd have to create DOM object, create an element for each person in the tree, and child elements for each attribute, all in some really ugly, hard to read code that I refuse to put here (that exercise is left to the reader...I've been there, and it sucks). In Groovy, to build this XML object, you would do something like this:

  1. def builder = new groovy.xml.MarkupBuilder()
  2. builder.people {
  3.   person {
  4.     firstName { "John" }
  5.     lastName {"Doe" }
  6.     emailAddress {"john.doe@example.com" }
  7.   }
  8.   person {
  9.     firstName { "George" }
  10.     lastName { "Bush" "
  11.    emailAddress { "prez@whitehouse.gov" }
  12.  }
  13. }

Can you tell what that does? Easy right?

I put Swing behind me years ago, 'cause it's such a nightmare, but here's a blog post that gives a quick look at building a simple Swing application in both standard Swing, and using Groovy's SwingBuilder class.

http://codetojoy.blogspot.com/2007/08/groovy-swingbuilder-and-secret-methods.html

Builders are not limited to what the guys at Groovy imagined. Through the magic of the Expando classes mentioned earlier, Groovy allows you to create your own builders with ease. More on these builders can be found on the Groovy web site.

3 - Unit Testing, Mocks, and Stubs

Unit testing in Groovy is so useful, and, well, groovy, that the "Groovy in Action" book mentioned earlier has an entire chapter devoted to it. Because I feel this is important, I am going to include a boatload of links, and an example or two for your convenience. Groovy makes unit tests, mock classes, and stubs much easier than standard JUnit tests. Almost easy enough to encourage developers to actually write tests. Here are some important reads:

The gist of it is that you can create you unit tests, to test your Java classes, in Groovy. Or, if you are testing your Groovy code, you can create in-line stubs and mocks to test your code. Jeff Brown gave some good examples at his NFJS presentation.

  1. class GroovyFileHelper {
  2.   def populateMessageBackwards(pathToFile, message) {
  3.     def f = new File(pathToFile)
  4.     if(f.exists()) {
  5.       throw new IllegalArgumentException(
  6.         "$pathToFile already exists.")
  7.     }
  8.     f.write(message.reverse())
  9.   }
  10. }

This class simply writes a message to a file in reverse. How would you unit test this in Java. Well, in reality, you really couldn't, not with a unit test. Maybe an integration test, because in Java you'd end up testing the file system (using the file.exists and file.write methods), not just your code. That's an integration test, my friend. Unless you can somehow throw a mock or stub at the problem. But how, oh how when the file object is inside the method? Groovy makes mocks and stubs easy.

Let's take a look at using the StubFor class to stub out the file object.

  1. void testFileContents() {
  2.   def messageWrittenToFile
  3.   def stubFile = new StubFor(File)
  4.   stubFile.demand.exists {false}
  5.   stubFile.demand.write {data ->
  6.     messageWrittenToFile = data
  7.   }
  8.   stubFile.use {
  9.     def helper = new GroovyFileHelper()
  10.     def path = '/Users/jeffbrown/someFile.txt'
  11.     helper.populateMessageBackwards(path, 'this is some data')
  12.   }
  13.   assertEquals 'wrong message was written to file',
  14.                'atad emos si siht',
  15.                messageWrittenToFile
  16. }
  17. void testFileAlreadyExists() {
  18.   def stubFile = new StubFor(File)
  19.   stubFile.demand.exists {true}
  20.   def msg = shouldFail(IllegalArgumentException) {
  21.     stubFile.use {
  22.       def helper = new GroovyFileHelper()
  23.       def path = '/Users/jeffbrown/someFile.txt'
  24.       helper.populateMessageBackwards(path,
  25.                                       'this is some data')
  26.     }
  27.   }
  28.   assertEquals 'incorrect exception message',
  29.                '/Users/jeffbrown/someFile.txt already exists.',
  30.                msg
  31. }

Here we are telling the JVM to use our stubFile in place of the File object within our stubFile.use block. How easy is that?

Mocks work the same way, but it's more of a white box test, where you can specify which methods are to be called while testing.

2 - Closures (and Delegates)

On the surface, closures seem a whole lot like Java's anonymous inner classes, though they are easier to use, and much more flexible. They have been shown in previous example without any explanation. Closures are basically blocks of code that take parameters. Sound a little bit like a function? Yep. A function that you can pass around, and which continues to have access to the local variables of where it was created, even when passed around. Like anonymous inner classes without the need to worry about that ugly "final" keyword.

  1. Closure add = {firstNumber, secondNumber ->
  2.   return firstNumber + secondNumber}
  3. }
  4. println "1 + 2 = ${add(1,2}}"

This simple concept can be used in unit tests, pretty much anywhere else you can think of that it might be useful to pass a function around.

Then there's the idea "delegates". Pretty cool stuff. You can define a closure, and then delegate all calls within that closure to any given class. For example, I might have a closure that looks like this:

  1. Closure appender = {first, second ->
  2.     append(first)
  3.     append(second)
  4. }

This closure could work with many different classes. Anything that has an "append" method. the StringBuffer comes to mind. So how do I get the appender to use the StringBuffer? Something like this:

  1. StringBuffer buffer = new StringBuffer()
  2. Closure appender = {first, second ->
  3.     append(first)
  4.     append(second)
  5. }
  6. appender.delegate(buffer)

Here the closure will call the append method on the buffer class. The possibilities here are endless!

1 - ExpandoMetaClass

The ExpandoMetaClass allows you to do the impossible. Add methods to existing classes. The String class, by design, can not be extended. So how in the world would you go about adding a "swapCase" method to the String class? (An incredibly useful method that would return a reverse-cased representation of a given String.) Easy. Use the ExpandoMetaClass from Groovy. (From the Groovy Web Site)

  1. String.metaClass.swapCase = {->
  2.   def sb = new StringBuffer()
  3.   delegate.each {
  4.      sb << (Character.isUpperCase(it as char) ? Character.toLowerCase(it as char) :
  5.                    Character.toUpperCase(it as char))
  6.   }
  7.   sb.toString()
  8. }

This actually changes the byte code for the String class, making the swapCase method available for the entire life of the JVM. Imagine being able to dynamically change any class you want to, on the fly.

This same methodology can be used to override methods in otherwise un-overridable files. Let's say you find a bug in some open source software you are using. You can either wait for the bug to be fix, fix it yourself and submit it back to the project, or override the method in your own code to make use of a quick fix.

I'm sure I'll look back at this post a few short months from now and have different options, and a different order, but as of right now, this stuff just rocks.

]]> http://joe.kueser.com/2007/10/what-makes-groovy-sogroovy/feed/ 21