Stuff I've learned recently...

On today’s Groovy Podcast, I mentioned that I was teaching a Groovy training class this week at Research Now in Plano, TX. That’s not how I said it, though. I said that I was broadcasting live in front of a studio audience and that they were the most amazingly awesome group I’ve ever encountered.

(Yeah, okay, sometimes I shamelessly pander for good evals. I’ll let you know if it worked after the class ends. Unless it doesn’t, in which case I probably won’t.)

During the podcast, I told my inestimable co-host, Peter Ledbrook, that we got a chance to use GPars in class. The app we used it on was all about the primary goal of the internet, which is to display cat pictures.

Peter then shamed me into writing a blog post about it, which you’re reading now.

I’ve actually written about this app before, for another client. My post there was originally entitled, “The Reason The Internet Was Invented, Or Cat Pictures FTW”, but the host changed it to the far more mundane Calling RESTful Services in Groovy.

The basic idea is that Flickr (remember them? Me neither) has a RESTful API that lets you search for photos. The “flickr.photos.search” request doesn’t require authentication, but does require a whole set of query parameters, including an API key.

Funny story: in order to get a Flickr API key, you actually have to register at Yahoo! Remember them, too? Yeah, neither did I.

At any rate, I registered and got my key, so I can now do the searches. Here’s the start of my Groovy script to do it:

[sourcecode language=”groovy”]
import groovy.json.*

String key = new File(‘flickr_key.txt’).text
String endPoint = ‘https://api.flickr.com/services/rest?’
def params = [method : ‘flickr.photos.search’,
api_key : key,
format : ‘json’,
tags : ‘kitty’,
nojsoncallback: 1,
media : ‘photos’,
per_page : 6]

// Build URL and download JSON data
String qs = params.collect { it }.join(‘&’)
String jsonTxt = "$endPoint$qs".toURL().text
[/sourcecode]
The query string is constructed from the map of params by running a collect on each element (which returns key=value for each Map.Entry) and then joining the resulting list with an ampersand. Notice the tags key was assigned to the word “kitty”.

The next part of my script writes out the results and appends them to a file.
[sourcecode language=”groovy”]
// write formatted JSON data to file
File f = new File(‘cats.json’)
if (f) f.delete()
f << JsonOutput.prettyPrint(jsonTxt)
println JsonOutput.prettyPrint(jsonTxt)
[/sourcecode]

Here’s a sample formatted JSON response:
[sourcecode language=”javascript”]
{
"photos": {
"page": 1,
"pages": 127979,
"perpage": 6,
"total": "767873",
"photo": [
{
"id": "17418175405",
"owner": "31469819@N02",
"secret": "9055856685",
"server": "5453",
"farm": 6,
"title": "A Ghostly Cat",
"ispublic": 1,
"isfriend": 0,
"isfamily": 0
},
{
"id": "16795470464",
"owner": "95966544@N07",
"secret": "cc4af0d44f",
"server": "8799",
"farm": 9,
"title": "Looking for a home",
"ispublic": 1,
"isfriend": 0,
"isfamily": 0
},
{
"id": "17228164988",
"owner": "92936362@N06",
"secret": "d42c68bbf3",
"server": "8734",
"farm": 9,
"title": "peaches the cat",
"ispublic": 1,
"isfriend": 0,
"isfamily": 0
},
{
"id": "17208304157",
"owner": "102705402@N02",
"secret": "582fff8f44",
"server": "8688",
"farm": 9,
"title": "This is the sweetest cat in the world!",
"ispublic": 1,
"isfriend": 0,
"isfamily": 0
},
{
"id": "17228717179",
"owner": "37561081@N07",
"secret": "eb8d0119fe",
"server": "7722",
"farm": 8,
"title": "\u65e9\u5b89",
"ispublic": 1,
"isfriend": 0,
"isfamily": 0
},
{
"id": "17388635206",
"owner": "127041099@N08",
"secret": "6310c6012a",
"server": "7745",
"farm": 8,
"title": "Tsim Tung Brother Cream (\u5c16\u6771\u5fcc\u5ec9\u54e5)",
"ispublic": 1,
"isfriend": 0,
"isfamily": 0
}
]
},
"stat": "ok"
}
[/sourcecode]
Note that nowhere in the various photo elements do you find a URL for the actual image. It turns out that to assemble the image you have to plug various pieces of the photo elements into a string, which is something Groovy is good at. First, however, I have to parse this and grab the photo elements:
[sourcecode language=”groovy”]
// parse JSON data and build URL for pictures
def json = new JsonSlurper().parseText(jsonTxt)
def photos = json.photos.photo
[/sourcecode]

The photos variable is now a list of maps for each photo, which I can transform into URLs using a collect:
[sourcecode language=”groovy”]
def images = photos.collect { p ->
String url =
"http://farm${p.farm}.staticflickr.com/${p.server}/${p.id}_${p.secret}.jpg"
url.toURL().bytes
}
[/sourcecode]
The Groovy string uses the farm, server, id, and secret elements of the response in each photo and builds a complete URL for the JPG image. Then I convert that to an actual URL and call getBytes() to return byte arrays.

I can then use a SwingBuilder to assemble a trivial GUI showing all the images:
[sourcecode language=”groovy”]
// build UI using Swing
new SwingBuilder().edt {
frame(title: ‘Cat pictures’, visible: true, pack: true,
defaultCloseOperation: WC.EXIT_ON_CLOSE,
layout: new GridLayout(0, 2, 2, 2)) {
images.each {
label(icon: new ImageIcon(it))
}
}
}
[/sourcecode]
That requires some additional imports:
[sourcecode language=”groovy”]
import groovy.swing.SwingBuilder

import java.awt.GridLayout
import javax.swing.ImageIcon
import javax.swing.WindowConstants as WC // Ooh, aliased imports
[/sourcecode]

Here’s where we improved the system using GPars. The download of the images can be done in a multithreaded fashion by adding a GParsPool:
[sourcecode language=”groovy”]
import static groovyx.gpars.GParsPool.*

// …

def images = []
withPool {
images = photos.collectParallel { p ->
String url =
"http://farm${p.farm}.staticflickr.com/${p.server}/${p.id}_${p.secret}.jpg"
url.toURL().bytes
}
}

// …
[/sourcecode]
That uses the default pool size, which is the number of processors you have plus one. The images are now downloaded concurrently as part of transforming the photo elements into byte arrays using collectParallel.

Here’s the whole script together:
[sourcecode language=”groovy”]
import static groovyx.gpars.GParsPool.*

import groovy.json.*
import groovy.swing.SwingBuilder

import java.awt.GridLayout
import javax.swing.ImageIcon
import javax.swing.WindowConstants as WC

String key = new File(‘flickr_key.txt’).text
String endPoint = ‘https://api.flickr.com/services/rest?&#8217;
def params = [method : ‘flickr.photos.search’,
api_key : key,
format : ‘json’,
tags : ‘kitty’,
nojsoncallback: 1,
media : ‘photos’,
per_page : 6]

// Build URL and download JSON data
String qs = params.collect { it }.join(‘&’)
String jsonTxt = "$endPoint$qs".toURL().text

// write formatted JSON data to file
File f = new File(‘cats.json’)
if (f) f.delete()
f << JsonOutput.prettyPrint(jsonTxt)
println JsonOutput.prettyPrint(jsonTxt)

// parse JSON data and build URL for pictures
def json = new JsonSlurper().parseText(jsonTxt)
def photos = json.photos.photo

def images = []
withPool {
images = photos.collectParallel { p ->
String url =
"http://farm${p.farm}.staticflickr.com/${p.server}/${p.id}_${p.secret}.jpg"
url.toURL().bytes
}
}

// build UI using Swing
new SwingBuilder().edt {
frame(title: ‘Cat pictures’, visible: true, pack: true,
defaultCloseOperation: WC.EXIT_ON_CLOSE,
layout: new GridLayout(0, 2, 2, 2)) {
images.each {
label(icon: new ImageIcon(it))
}
}
}
[/sourcecode]

Here is the result of a sample run:

So there you have it, except for the stupid Flickr key, which I decided to let you register for on your own. Hey, I had to go through that pain, so everybody else does, too.

Well, not everybody. As part of my pandering for evals technique, I did give my key to the students in my class, who no doubt will reward me with stellar evals once we’re done. Probably. It could happen. Either way, at least there were cat pictures, and that’s a Good Thing.

When I first started learning Groovy, I took to collect pretty quickly. The current trend of adopting “functional programming” practices works well in Groovy, though the names of the methods are somewhat surprising. For example, collect is like map, findAll is the equivalent of filter, and inject is the proposed replacement for reduce (or whatever the similar process is for your favorite language).

As a trivial example, in Groovy you can write:
[sourcecode language=”groovy”]
(1..20).collect { it * 2 } // double them all
.findAll { it % 3 == 0 } // find the doubles divisible by 3
.sum() // add them up
[/sourcecode]
which is a functional style, even though Groovy is an object-oriented language.

Notice, however, that I didn’t use inject. That’s not an accident, of course. For years, while I “got” collect and findAll, I never found a usage for inject that couldn’t be done in an easier way. The inject version of the above example would be:
[sourcecode language=”groovy”]
(1..20).collect { it * 2 } // double them all
.findAll { it % 3 == 0 } // find the doubles divisible by 3
.inject(0) { acc, val -> acc + val } // add them up
[/sourcecode]
That seems like a lot of work compared to the sum method, especially when I always had trouble remembering exactly what the arguments to the closure meant.

That changed recently. One of the examples I use when teaching Groovy to Java developers is do some basic sorting. I like that example, because it shows not only how easy it is to replace anonymous inner classes with closures, but also because it shows how much the Groovy JDK simplifies coding.

As a preface to my example, consider making an ArrayList of strings:
[sourcecode language=”groovy”]
def strings = ‘this is a list of strings’.split()
assert strings.class == java.lang.String[]
[/sourcecode]
The split method splits the string at spaces by default, and returns, sadly, a string array. What I want is a List, and converting an array into a List is a special blend of Java awkwardness and verbosity, though the code isn’t too bad once you’ve seen it.

The conversion is trivial in Groovy, however.
[sourcecode language=”groovy”]
List strings = ‘this is a list of strings’.split()
assert strings.class == java.util.ArrayList
[/sourcecode]
Just replace def with the datatype you want, and Groovy will do its best to do the conversion for you. 🙂

To sort a list, Java has the various static sort methods in the java.util.Collections class. The sort method with no arguments does the natural, alphabetical (more properly, lexicographical, where there capital letters come before the lowercase letters) sort.

[sourcecode language=”groovy”]
List strings = ‘this is a list of strings’.split()
Collections.sort() // natural sort (alphabetical)
assert strings == [‘a’, ‘is’, ‘list’, ‘of’, ‘strings’, ‘this’]
[/sourcecode]
This sorts the strings in place (a destructive sort) and returns void, so to see the actual sort you have to print it.

How do you test this? I wrote an assert that hardwired the results, because I knew what they had to be. That’s hardly generalizable, however, and this is where inject comes in.

Have you ever looked at the definition of inject in the GroovyDocs? Here it is, from the class org.codehaus.groovy.runtime.DefaultGroovyMethods.

public static T inject(E[] self, U initialValue, @ClosureParams(value=FromString.class,options=”U,E”) Closure closure)

Iterates through the given array, passing in the initial value to the closure along with the first item. The result is passed back (injected) into the closure along with the second item. The new result is injected back into the closure along with the third item and so on until all elements of the array have been used. Also known as foldLeft in functional parlance.

Parameters:
self – an Object[]
initialValue – some initial value
closure – a closure

Returns:
the result of the last closure call

You would be forgiven for being seriously confused right now. I’ve been using Groovy since about 2007 and if I didn’t already know what inject did, I’d be seriously confused, too.

The DefaultGroovyMethods class contains lots of methods that are added to the library at runtime via Groovy metaprogramming. In this case, the inject method is added to collection (the first argument above). The second argument to inject is an initial value. An initial value to what, you say? The third argument to inject is a closure, and it takes two arguments, and the second argument to inject is the initial value of the first argument of the closure. The subsequent values to that argument are the result of the closure. The second argument to the closure is each element of the collection, in turn.

I expect that almost nobody actually read that last paragraph. Or, more likely, you started it and abandoned it somewhere in the middle. I can hardly blame you.

As usual, the indefatigable Mr. Haki comes to the rescue. Here is one of his examples:

[sourcecode language=”groovy”]
(1..4).inject(0) { result, i ->
println "$result + $i = ${result + i}"
result + i
}
[/sourcecode]
and the output is:

0 + 1 = 1
1 + 2 = 3
3 + 3 = 6
6 + 4 = 10

The value of result starts at the initial value (here, 0), and is assigned the result of each execution of the closure.

That’s the sort (no pun intended) of example I’d seen before, and because I always associated inject with accumulators, I never actually needed it. After all, the Groovy JDK adds a sum method already.

The key is to note that the value of “result” is actually whatever is returned from the closure (Mr. Haki’s second example illustrates this beautifully — seriously, go read his post). This actually makes it easy to use to test the sort.

Try this out for size:
[sourcecode language=”groovy”]
List strings = ‘this is a list of strings’.split()
Collections.sort(strings)
strings.inject(”) { prev, curr ->
println "prev: $prev, curr: $curr"
assert prev <= curr
curr // value of ‘prev’ during next iteration
}
[/sourcecode]
The result is:

prev: , curr: a
prev: a, curr: is
prev: is, curr: list
prev: list, curr: of
prev: of, curr: strings
prev: strings, curr: this

Since the closure returns the current value, that becomes the value of prev during the next iteration.

Actually, this can be simplified too. As of Groovy 1.8, there’s now an inject method that leaves out the initialization value. When you call it, the first two elements of the collection become the first two arguments of inject. In other words, now I can do this:
[sourcecode language=”groovy”]
List strings = ‘this is a list of strings’.split()
Collections.sort(strings)
strings.inject { prev, curr ->
println "prev: $prev, curr: $curr"
assert prev <= curr
curr // value of ‘prev’ during next iteration
}
[/sourcecode]
The output now is:

prev: a, curr: is
prev: is, curr: list
prev: list, curr: of
prev: of, curr: strings
prev: strings, curr: this

Sweet. Now I have a real, live use case for inject. 🙂 I promised you more, however. The title of this post refers to Elvis and spaceships, too.

Assume you want to sort the strings by length. In Java, when you can’t modify the class to be sorted (String), you use the two-argument sort method in Collections. The second argument is of type java.util.Comparator, which gives rise to the dreaded anonymous inner class monster:
[sourcecode language=”groovy”]
List strings = ‘this is a list of strings’.split()
Collections.sort(strings, new Comparator<String>()) { // R: Holy anonymous inner class, Batman!
int compare(String s1, String s2) { // B: Yes, Robin, with generics and everything.
s1.size() <=> s2.size() // R: Gosh, gee, and a spaceship!
}
})
assert strings == [‘a’, ‘is’, ‘of’, ‘this’, ‘list’, ‘strings’]
assert strings*.size() == [1, 2, 2, 4, 4, 7] // R: Holy spread-dot operator, too!
// B: Dude, seriously, get a grip.
[/sourcecode]
The spaceship operator returns -1, 0, or 1 when the left side is less than, equal to, or greater than the right side. It’s like a comparator, except the values are fixed to -1, 0, and 1.

The nice thing about the spread-dot operator here is that it doesn’t care whether the resulting strings are also alphabetical or not. The fact that equals length strings were also sorted alphabetically is just a side effect of the algorithm.

One of the common idioms in the Groovy JDK is to take static methods in Java and make them instance methods in Groovy. Here, the sort method is a static method in the Collections class. The Groovy JDK makes it an instance method in Collection (singular).

[sourcecode language=”groovy”]
List strings = ‘this is a list of strings’.split()
strings.sort { s1, s2 -> s1.size() <=> s2.size() } // R: Holy closure coercion, Batman!
// B: No, the instance method takes a closure.
// Seriously, did you remember your ADHD meds today?
assert strings*.size() == [1, 2, 2, 4, 4, 7]
[/sourcecode]

The sort method in Groovy is now an instance method, which takes a one- or two-argument closure. The two-argument variety is implemented like a traditional comparator, meaning you return negative, zero, or positive as usual.

Even better, the one-argument version of sort says, in effect, transform each element into a number and Groovy will sort the numbers and use that as a way to sort the collection.

[sourcecode language=”groovy”]
List strings = ‘this is a list of strings’.split()
strings.sort { it.size() } // R: Everything is awesome!
assert strings*.size() == [1, 2, 2, 4, 4, 7] // B: Shut up kid, or you’ll find yourself floating home.
[/sourcecode]

Here’s the best part. What if you want to sort by length, and then sort equal lengths reverse alphabetically? (I’ll use reverse alpha because the length sort also did alphabetical by accident).

Now I can use Elvis and spaceships together:

[sourcecode language=”groovy”]
List strings = ‘this is a list of strings’.split()
strings.sort { s1, s2 ->
s1.size() <=> s2.size() ?: s2 <=> s1
}
[/sourcecode]

The Elvis operator says if the result is true by the Groovy Truth, use it, else use a default. Here it means do the length comparison and if the result is non-zero, we’re good. Otherwise do the (reverse) alphabetical comparison.

R: So that’s Elvis being carried back to his home planet by two tandem spaceships, right? Meaning it’s the fat Elvis from the 70s and not the thin Elvis from the 50s?
B: BAM! POW! OOF!

Here, finally, is a test based on inject for that sort:
[sourcecode language=”groovy”]
strings.inject { prev, curr ->
assert prev.size() <= curr.size()
if (prev.size() == curr.size()) {
assert prev >= curr
}
curr
}
[/sourcecode]

There you have it: Elvis, spaceships, and inject all in a dozen lines of code. Now you add that to your Groovy utility belt.

(B: POW! BAM! OOF!)

I’ll report about the SpringOne2GX conference soon, but I’m fighting a cold at the moment and the medication has put me in a rather bleary state. Thus, the following bit of random Groovy whimsy…

In this post, I’ll use Groovy to access a publicly available RESTful web service, parse the downloaded data, and build a GUI to hold the resulting images. The code will demonstrate the Groovy JDK, maps, the collect method, I/O processing, and the builder pattern, all to achieve its ultimate goal: looking at cat pictures.

A Flickring Light In The Darkness

There are many so-called RESTful web services available to the general public. Despite the name, however, most only support GET requests. This isn’t terribly surprising, since POST, PUT, and DELETE would require some kind of transaction, and security, and all sorts of protection against the sort of damage reminiscent of YouTube comments[1].

Examples of that sort of services include Open Weather Map (http://openweathermap.org/api), Currency Exchange Rates (http://openexchangerates.org), the Bing[2] Maps REST services (http://msdn.microsoft.com/en-us/library/ff701713.aspx), the Google Maps Geocoder (https://developers.google.com/maps/documentation/geocoding/) and the source for this article, Flickr (https://secure.flickr.com/services/developer). Each supports HTTP GET requests only.

If a RESTful web service only supports GET requests, does that make it a GETful service? If so, and it’s also stateless, does that make it a FORGETful web service? Thank you, thank you. Try the veal, and please remember to tip your wait staff.

Believe it or not, Flickr used to be the definitive site for image sharing, and some people still use it. Access requires a key, which means you need to register with Yahoo!, another web site that used to matter long, long ago when the web was shiny and new.

Why use it here? It’s available, it’s free, and, most important of all, it’s got cat pictures.

Feeling Groovy

Groovy is one of the new family of languages that compiles to bytecodes for the Java Virtual Machine. It’s simpler than Java, yet much more powerful, and has an easy learning curve for existing Java developers. It’s cool in its own right, and also forms the basis of interesting projects like Grails and Gradle.

Hey, I even wrote a Java/Groovy integration book about it.

Now on to the Groovy. Let’s assume you register and receive your special key. Save it in a file called flickr_key.txt, so you can access it this way:

[sourcecode language=”groovy”]
String key = new File(‘flickr_key.txt’).text
[/sourcecode]

Accessing a property (like text here) in Groovy is the same as invoking the corresponding getter or setter method. Here, the Groovy JDK adds the getText method to File, which returns the contents of the file.

The base URL for the web service is:

[sourcecode language=”groovy”]
String endPoint = ‘https://api.flickr.com/services/rest?&#8217;
[/sourcecode]

I included the “?” because I want to append the generated query string to the end point to get the complete URL.

The Flickr API uses a query string with a lot of parameters. Here I add them to a Groovy map.

[sourcecode language=”groovy”]
def params = [method: ‘flickr.photos.search’, api_key: key,
format: ‘json’, tags: ‘cat’, nojsoncallback: 1,
media: ‘photos’, per_page: 6]
[/sourcecode]

I’m calling the flickr.photos.search method with the api_key. I want JSON data back, but not as a JSON callback, and I want photo data using the cat tag. It’s not terribly complicated, but there are a lot of parameters.

The cool part is that a Groovy map like this can be converted to a query string using a very common idiom. The collect method applied to a map generates a list by applying a closure to each element of the original list. Therefore I can generate the query string thusly:

[sourcecode language=”groovy”]
def qs = params.collect { k,v -> "$k=$v" }.join(‘&’)
[/sourcecode]

The two-argument closure takes each key/value pair and returns a string where the key equals the value. Then the join method applied to the list creates a string whose entries are separated by ampersands.

That means the whole URL is defined by "$endPoint$qs". I can then use the toURL method from the Groovy JDK to convert the string to a URL[3], and the text parameter invokes getText, returning the total response.

I can now use the cool JsonOutput.prettyPrint(txt) method to format the output and write it to a file.

[sourcecode language=”groovy”]
File f = new File(‘cats.json’)
if (f) f.delete()
f << jsonTxt
println JsonOutput.prettyPrint(jsonTxt)
[/sourcecode]

Here’s a sample from that output:

[sourcecode language=”javascript”]
{
"photos": {
"page": 1,
"pages": 882777,
"perpage": 6,
"total": "5296661",
"photo": [
{
"id": "15077663928",
"owner": "125421155@N06",
"secret": "dc605f2671",
"server": "3837",
"farm": 4,
"title": "Mornings with bb kitty",
"ispublic": 1,
"isfriend": 0,
"isfamily": 0
},
{ … },
{ … },
{ … },
{ … },
{ … }
]
},
"stat": "ok"
}
[/sourcecode]

From JSON to Cat Pictures

Each photo block has the components necessary to assemble the URL to retrieve it, which is way more complicated than it needs to be but is still doable. Here’s the code for that part.

[sourcecode language=”groovy”]
def json = new JsonSlurper().parseText(jsonTxt)
def urls = json.photos.photo.collect { p ->
"http://farm${p.farm}.staticflickr.com/${p.server}/${p.id}_${p.secret}.jpg"
}
[/sourcecode]

The JsonSlurper has a parseText method that converts the received JSON string into a Groovy map. Then walking the map by calling json.photos.photo gets all the photo objects, and the collect block converts each of them into a URL.

All that remains is to access all the photo URLs and populate a simple GUI with them. One simple way to do that is to use Groovy’s SwingBuilder class.

[sourcecode language=”groovy”]
new SwingBuilder().edt {
frame(title:’Cat pictures’, visible: true, pack: true,
defaultCloseOperation: WindowConstants.EXIT_ON_CLOSE,
layout:new GridLayout(0, 2)) {
urls[0..5].each { String url ->
label(icon:new ImageIcon(url.toURL()))
}
}
}
[/sourcecode]

The SwingBuilder has an edt method, which builds the UI on the event dispatch thread. The frame “method” instantiates a JFrame with the given title, makes it visible, and packs it as small as possible. The GUI uses a GridLayout to make two columns of equally-spaced elements, each of which is a JLabel that contains an ImageIcon with the individual photo URLs.

The result is a display of the most recent six pictures tagged cat in Flickr, which can result in almost anything[4].

Here’s a sample view:

Don’t ask me about the monkey. I have no idea what that’s about either.

So what have we learned?

1. Groovy maps can be converted to query strings using a closure and the join method
2. The Groovy JDK adds methods to Java library classes that you wished were there all along
3. Groovy builders can make Swing programming almost, but not quite, pretty cool
4. I can haz kitteh pics

The entire script from this article is part of a GitHub repository called IntroGroovy. Drill down to the src/main/groovy/flickr directory. You’ll need to add your own Flickr key, but after that, go for it. Just don’t be surprised, apparently, if you get monkeys or tractors mixed in with your cat pictures.

I suppose now I should go and reimplement the whole script in LOLCODE.

I knew as soon as I wrote about implementing a simple prime number algorithm using Groovy that someone would find a more elegant way of solving the problem. In this post, I want to highlight some of the responses I received.

In my previous post, The Closure Of No Return, I discussed implementing an isPrime method that worked for relatively small integers. The algorithm is to try to divide the given number by all integers from two up to the square root of the number, rounded up.

My initial attempt, and the actual motivation for the blog post, was to demonstrate that if you use a return keyword inside a closure, you only return from the closure. So my initial implementation didn’t work:
[sourcecode language=”groovy”]
// THIS DOESN’T WORK
boolean isPrime1(int x) {
if (x == 2) return true
int limit = Math.sqrt(x) + 1
(2..limit).each { n ->
// nice try, but a return in a closure
// returns only from the closure
if (x % n == 0) return false
}
return true
}
[/sourcecode]
The each method takes a closure as an argument, which is like calling a completely separate method. The return statement inside the closure returns from that method, but not from the each loop itself.

In order to return the proper value, I introduced a local variable, called result, which I assigned inside the closure and then returned:
[sourcecode language=”groovy”]
boolean isPrime2(int x) {
if (x == 2) return true
boolean result = true
int limit = Math.sqrt(x) + 1
(2..limit).each { n ->
if (x % n == 0) {
result = false
// can’t break out of the loop
}
}
return result
}
[/sourcecode]
Since I couldn’t use the break keyword inside the loop, this implementation was forced to check all the integers up to limit. I therefore switched at that point to Groovy’s for-in loop, which does allow the break:
[sourcecode language=”groovy”]
boolean isPrime3(int x) {
if (x == 2) return true
boolean result = true
int limit = Math.sqrt(x) + 1
for (n in 2..limit) {
if (x % n == 0) {
result = false
break
}
}
return result
}
[/sourcecode]
That was my final implementation in the blog post. I posted that one the web and waited for the corrections to roll in.

One commenter, Eric Johansson, pointed out that once I switched to the for-in loop, I could go back to using return again and eliminate the local variable result. Of course that’s true, and I missed it because of the steps I went through to write the code. I wonder how often such hysteresis loops occur in practice.

Another person commenting on the post, identified at Tim but without an email address or a link, suggested using the any method:
[sourcecode language=”groovy”]
boolean isPrime3(int x) {
if (x == 2) return true
int limit = Math.sqrt(x) + 1
!(2..limit).any { n ->
x % n == 0
}
}
[/sourcecode]
The hope here is that the any method would stop at the first number that satisfied the closure. I wasn’t sure that was true, so I looked at the source code for Groovy, which can be found on GitHub. The any method is shown in the Groovy JDK as being part of the java.lang.Object class. One way methods are added to the Java standard library is through the metaprogramming methods in
org.codehaus.groovy.runtime.DefaultGroovyMethods. I looked in that class and found the any implementation, which adds the any method to the java.lang.Object class:
[sourcecode language=”groovy”]
// from DefaultGroovyMethods
public static boolean any(Object self, Closure closure) {
BooleanClosureWrapper bcw = new BooleanClosureWrapper(closure);
for (Iterator iter = InvokerHelper.asIterator(self); iter.hasNext();) {
if (bcw.call(iter.next())) return true;
}
return false;
}
[/sourcecode]
If I’m interpreting this correctly, the iterator walks through each element one by one and returns true the first time an element satisfies the closure. In other words, yes, this approach would work and leave the loop at the proper time.

Soren (sorry, I don’t know how to put the line through the “o”) Berg Glasius (http://twitter.com/sbglasius) suggested using the every method instead, which would also probably do the job.

Both great developer Jochen Theodorou and the indefatigable Tim Yates immediately identified the obvious alternative that I missed. Here’s Tim’s solution (which is a slight variation on Jochen’s):
[sourcecode language=”groovy”]
boolean isPrime5(int x) {
int limit = Math.sqrt(x) + 1
x == 2 || !(2..limit).find { n -> x % n == 0 }
}
[/sourcecode]
I remembered the findAll method, which I used in my tests, but I forgot all about the find method, which returns the first element that satisfies the closure. That’s pretty ironic, too, because (in Grails especially) I normally accidentally use find when I meant findAll.

(As an aside, as soon as I saw Tim’s name, I assumed his solution was going to be both elegant and have the take method in there somewhere. I was half right.)

The only problem I have with these solutions is that while they work, they invalidate the real reason for my blog post, which was to emphasize that a return inside a closure returns only from the closure. Still, that last one feels like a really good way to solve the actual problem, so I’m going to use that in the future.

The best part is that everyone who suggested an alternative was quite friendly about it. I may have felt a bit foolish for missing these alternatives, but that’s my own pressure on myself. One of the best features about the Groovy community is how helpful and easy to work with everyone is, which I really like. Hopefully by posting those solutions here, I’m paying some of that forward.

(Thanks to everyone who responded, whether I quoted them here or not. I really appreciate the feedback.)