If a method arg is a closure, for crying out loud pass it a closure

This is a (mildly) embarrassing post, because it demonstrates how in my transition to functional programming I missed something important. I get it now, though, and I might as well help others avoid the same mistake I made.

I teach a lot of Grails training classes, and one question that always comes up is how to map to existing databases rather than generate the schema from the Grails application. Hibernate (and therefore Grails) would love to generate the database schema for you, for a variety of reasons, but mostly because going the other way isn’t unique. You have to make a lot of decisions about a domain model when you reverse-engineer an existing schema, ranging from multiplicities in relationships to how to map many-to-manys to directionality and more.

In my standard Grails course, rather than create a database we can map to, I go with an existing, freely available sample. For years I’ve chosen the Sakila sample database from MySQL.

(As an aside, it took me years to realize that the word Sakila is actually intended to be a subtle joke. It’s the letters SQL with some vowels thrown in to make it possible to pronounce the word, with the “Q” replaced by a “k”. Go figure. As it turns out, it’s also the name of their dolphin emblem, but that’s neither here nor there.)

Over the years I’ve tried to map the Sakila schema to a Grails domain model, with varying degrees of success. I think I have it all worked out now, but that’s the subject for another blog post. Here, instead, I want to talk about stored procedures.

Many of my clients want to use Grails with a database that has lots of stored procedures in it. Hibernate doesn’t like that. Hibernate wants to map all the domain classes directly to tables, without going through any possible intermediaries. While it is possible to invoke a stored procedure from Hibernate, it’s a bit awkward, mostly because Hibernate doesn’t want to do it.

(Length of Java Persistence Using Hibernate: about 850 pages. Number of pages that discuss stored procedures: about 5.)

That’s where Groovy (as opposed to Grails) comes in. The Groovy API includes the wonderful groovy.sql.Sql class, which is a simple, but effective, façade over JDBC. That class will open and close connections, eliminate all the annoying boilerplate code associated with JDBC, and more. If I ever have to write raw SQL code, I always switch to groovy.sql.Sql rather than use JDBC.

(That’s not quite true. The JdbcTemplate class from Spring is nearly as helpful. If I don’t have Groovy available and I have to do JDBC, I go with that.)

Let me get specific. The Sakila database represents a video store (which shows how old that is). It has tables representing stores, and inventory, and actors, and films, and more. But it also contains a handful of stored procedures, one of which is called film_in_stock. According to the documentation, the film_in_stock procedure takes two input parameters (the id of the film and the id of a store) and one output parameter (the number of copies of that film currently at that store). The example they show is:

mysql> call film_in_stock(1, 1, @count);
| inventory_id |
| 1            |
| 2            |
| 3            |
| 4            |
4 rows in set (0.06 sec)

Query OK, 0 rows affected (0.06 sec)

mysql> select @count;
| @count |
| 4      |
1 row in set (0.00 sec)

There are four copies of film 1 (“Academy Dinosaur”) at store 1 (a store at “47 MySakila Drive” in Alberta). This provides me with a test case:

import spock.lang.*

class StoreProcServiceIntegrationSpec extends Specification {
    def storedProcService  // inject the service

    void "call film_in_stock stored procedure"() {
        storedProcService.callFilmInStock(1, 1) == 4

This assumes my call to the stored procedure happens in a class called StoredProcService. I have to use an integration test here, because I want to use the real database, but that means I can rely on Spring dependency injection to get the service into the test.

To access the Sakila database from a Grails app, I configured my conf/DataSource.groovy file to include the dataSource properties:

import org.hibernate.dialect.MySQL5InnoDBDialect

dataSource {
    pooled = true
    jmxExport = true
    driverClassName = "com.mysql.jdbc.Driver"
    username = "root"
    password = ""
    dialect = MySQL5InnoDBDialect
// ...
environments {
    development {
        dataSource {
            dbCreate = "validate"
            url = "jdbc:mysql://localhost:3306/sakila"
    test {
        dataSource {
            dbCreate = "validate"
            url = "jdbc:mysql://localhost:3306/sakila"
// ...

(Yeah, I have super high security on this database. Don’t even think about breaking in. You’d never guess that the root user has no password whatsoever. I mean, who would do such a ridiculous thing?)

So the default data source in my Grails app is the Sakila database, using a MySQL driver that I have listed in the conf/BuildConfig.groovy file:

dependencies {
    runtime 'mysql:mysql-connector-java:5.1.29'
    test "org.grails:grails-datastore-test-support:1.0-grails-2.4"

Again, nothing terribly unusual here.

The key observation is that the dataSource reference in the config file refers to a Spring bean, which can be injected in the usual manner. So I created a Grails service called StoredProcService and specified the dataSource bean as a dependency.

class StoredProcService {
    def dataSource
    // ...

The GroovyDocs for the Groovy API show that the groovy.sql.Sql class has a constructor that takes a data source, so I’m all set. Then, to call the stored procedure, I need to invoke the call method from that class.

This is where life gets interesting, and ultimately tricky. The procedure I want to call has both input and output parameters, so my call has to take that into account. It turns out that the way to call a stored procedure with both inputs and outputs is to invoke:

void call(String sql, List<Object> params, Closure closure)

The SQL string uses the JDBC escape syntax for stored procedure calls. The params list take the input parameters and placeholders for the output parameters, and the closure is then invoked with the output parameters.

Wait, what? That’s a little fast. Here’s the actual call, or at least this is the version I had before last weekend:

import groovy.sql.Sql

class StoredProcService {
    def dataSource
    int callFilmInStock(filmId, storeId) {
        String sqlTxt = '{call film_in_stock(?,?,?)}' // JDBC escape syntax
        Sql db = new Sql(dataSource)  // use the injected datasource
        db.call(sqlTxt, [filmId, storeId, Sql.INTEGER]) { count ->
            // use the count here

The Sql class provides constants like “static OutParameter INTEGER” to represent output variable in the stored procedure call. Then the last argument is a closure that has as many arguments as there are output parameters (in this case, one, which I called count).

Now, though, I have a problem. I’d like my callFilmInStock method to return the result of invoking the film_in_stock stored procedure, i.e., the count of films at that store. The problem is, I can’t just say return count inside that closure, because returning from a closure returns only from the closure, not the calling method.

I’ve blogged about that before, and even submitted a variation to Baruch Sadogursky as a Groovy Puzzler, but this is where I first encountered that problem.

My solution was always to create a local variable outside the call, assign the count to that variable, and return the variable:

int callFilmInStock(filmId, storeId) {
    String sqlTxt = '{call film_in_stock(?,?,?)}' // JDBC escape syntax
    Sql db = new Sql(dataSource)  // use the injected datasource
    int result = 0
    db.call(sqlTxt, [filmId, storeId, Sql.INTEGER]) { count ->
        result = count
    return result

This works, and (sigh) I’ve been teaching this approach for some time now. I’ve always been uncomfortable with it, though, and when I started digging into Java 8 lambdas I realized why. I’m using a closure here and relying on it having a side effect, which is to modify a variable defined outside the closure. In fact, in Java 8, lambdas are definitely not supposed to do that. The only variables lambdas are supposed to access from outside the lambda are those that are “effectively final”, meaning they’re never modified. Groovy closures don’t have that limitation, but I still had this nagging feeling that I was, as they say, doing it wrong.

Last weekend, the new NFJS season started for me in Minneapolis, and I got a chance to talk about this to the inimitable Venkat Subramaniam, who writes books on this stuff (among other things). After I explained the problem, he thought about it for about five whole entire minutes and said that I should be passing the method a closure, not returning an integer.

The right way to write my service function is to add a closure to the method signature and use it in the sql call:

void callFilmInStock(filmId, storeId, closure) {
    String sqlTxt = '{call film_in_stock(?,?,?)}' // JDBC escape syntax
    Sql db = new Sql(dataSource)  // use the injected datasource
    db.call(sqlTxt, [filmId, storeId, Sql.INTEGER], closure)

Wow, that’s so much simpler. The client now passes in a closure that uses the returned value, rather than trying to kludge returning the value itself. That means the test case becomes:

void "call film_in_stock stored procedure"() {
    storedProcService.callFilmInStock(1, 1) { count ->
        assert count == 4

(This uses the normal Groovy idiom where a method taking a closure as its last argument can put the closure after the parentheses.)

This test passes just as the previous one did, even though the method return type is now void.

That’s the part I never got before. The groovy.sql.Sql.call(String, List, Closure) method takes a closure as its last argument, which means I can supply the closure myself and the method will use it with the returned count.

When I learned about functional programming, I got the idea of transforming collections rather than iterating over them, and using filters to select only the values I want, and reducing the results down to single values. I got that I’m supposed to favor immutability wherever possible. What I apparently hadn’t grokked was sending closures as method arguments and how that simplified everything. I’m still not sure I’m all the way there, but I’m certainly a lot closer now.

Over the weekend I tweeted that Venkat had fundamentally changed my understanding of functional programming, which is both cool and seriously annoying. Frankly, those are also words I would use to describe Venkat. If he wasn’t such a nice guy, he would be insufferable, mostly due to sheer jealousy. But we rapidly learn on the NFJS tour never to compare ourselves to Venkat in any way or you’ll just drive yourself crazy. Just don’t tell him I said that.

Now I have to go update my Grails materials…

Now Co-Hosting the Groovy Podcast…

When I first starting learning Groovy in a serious way, one tool I enjoyed was listening to the Grails Podcast. Glen Smith and Sven Haiges led a discussion about Grails-related issues on a regular basis. Of course, since they talked about new developments in Grails, they also had to cover new developments in Groovy, so the podcast was a valuable resource for both.

At the beginning of each podcast, Glen would say that he was podcasting from Canberra, Australia, and Sven was podcasting from San Jose, California. Of course, Sven might have been in CA, but Sven is actually a European and eventually moved back to Munich. That led me to contact Glen and ask to be the third person in the booth, arguing (a) that they needed an American, too, and (b) together we’d be Glen, Sven, and Ken, and how cool was that?

(To be honest, I didn’t care whether the podcast included an American or not. It just seemed a stronger argument than the fact that our names rhymed.)

The Grails Podcast went on for several years, but underwent significant changes over time and became far less frequent. Eventually Peter Ledbrook (inimitable co-author, with Glen, of Grails in Action) took over, and a year ago he renamed it the Groovy Podcast.

Meanwhile, whenever I saw Peter at a conference, I casually mentioned that I wanted to be involved in the new podcast. Finally, last year at the SpringOne2GX conference, Peter finally broke down and said he’d be willing to let me work with him.

Okay, that’s perhaps a bit too self-deprecating, but when you want something like that you have to keep prodding until they say yes. I often tell my son that in order to be at the right place at the right time, you have to be at the wrong place at the wrong time a lot.

So, in the end, I’m very happy to announce that I’m now the co-host of the Groovy Podcast. Peter uses Google Hangouts to record the podcast, so anyone can join in real time. The results are published in the Groovy Podcast YouTube channel in video form and on PodBean for those who just want the audio feed.

I participated in episode 6 back on Feb 5, and we just recorded and published episode 7 on Feb 20. The goal is to get the podcast back on a regular, two-week schedule, which should make it easier to build a following again. Episode 5, from January, included a discussion with Groovy project lead Guillaume Laforge and Grails project lead Graeme Rocher about the change in Pivotal support for the projects, so that one is worth watching regardless.

Here’s an embedded version of episode 7, assuming that works correctly:

I should also mention that the show notes for the last couple of podcasts are available on GitHub. That’s now a public repo, so anyone can see them and potentially suggest topics for future discussions.

So far I’ve written this post assuming you know me already, but it’s possible that you found this from the podcast itself and are wondering who I am and why I would have anything productive to say about the Groovy ecosystem. Let me present a short bio here.

My name is Ken Kousen. The last name is pronounced as though it were spelled cousin, like the relative, for reasons unknown but probably having something to do with my grandfather’s very heavy eastern European accent. I’ve been working with Groovy since late 2006, but much more as a user than as a contributor. Eventually I started writing about the language, and my book on adding Groovy to Java projects to make development easier, entitled Making Java Groovy, was published by Manning in the Fall of 2013. I’m currently working on another book, this time from O’Reilly, entitled Gradle for Android, covering the new Gradle build system for Android projects. That book will be available in early access mode Real Soon Now(TM).

I run a one-person company called Kousen IT, Inc., where my day job is teaching technical training courses on all areas related to Java, specializing in open source projects like Spring, Hibernate, Android, and naturally Groovy, Grails, Gradle, and more. I do some consulting and mentoring as well, but my schedule tends to fill with training classes so quickly that it’s hard to arrange for other activities.

I’m also a regular speaker on the No Fluff, Just Stuff conference tour, which meets on roughly 20 to 25 weekends a year at various cities throughout the U.S. On the tour I mostly speak about Groovy-related projects, but I also discuss Android, Java 8, and a few other areas like Bayesian statistics and even “Managing Your Manager”.

In fact, my “Managing Your Manager” talk has been sufficiently well received at previous conferences that it will be the opening day keynote at the DevNexus conference in Atlanta the week of March 9, 2015. I’ve also spoken at the U.S. version of the Gr8 conference several times, and (spoiler alert!) will be giving a keynote there in July discussing The Mobile World and Groovy’s role in it.

Please feel free to contact me with questions, comments, or any good IT-related jokes, which I’ll freely reuse and even give you credit/blame if you want. If you and/or your company are interested in training classes, you should definitely contact me sooner rather than later, because as the Groovy Podcast explodes in popularity and my reputation skyrockets as a result, my prices will no doubt also become appropriately astronomical. So get your requests in now, while I’m still a relative nobody, at least compared to Peter.

Years ago I used to joke to my wife about having a 10-year plan to becoming an overnight sensation (btw, I’m currently in year 15…). I thought that winning a JavaOne Rock Star award in 2013 was the amazing accomplishment of a lifelong dream, but being a part of this podcast is so beyond epic —

Okay, I’ll stop now. Let’s just say I’m really happy to be here, and if you’re at all interested in the Groovy world you should enjoy the podcast. We’re certainly having fun making it.

Groovy/Grails – Pivotal == Opportunity

The news broke this morning that Pivotal plans to withdraw its financial support from the Groovy and Grails projects by the end of March, 2015. The heads of both projects, Guillaume Laforge and Graeme Rocher, have each blogged about it, with their typical grace, thanking Pivotal for the opportunity and assuring everybody that both projects have a long, bright future ahead of them.

Since I.T. is a field that frequently has very little memory, let me remind people about a couple of items:

  1. Groovy existed as a successful open source project for at least four years before SpringSource started supporting it. Grails started as an offshoot of Groovy and was just as popular.
  2. Several of the core teams members of both projects formed the G2One company, which was sufficiently successful in its first year that SpringSource acquired it in the first place

Neither Groovy nor Grails are radical departures from their underlying technologies. That makes them quiet projects — they’re popular, but they aren’t showy. They never have been popular among the hipster IT community, but they get the job done. It’s so easy to add Groovy to existing Java projects that most developers who do it don’t feel obligated to crow about it. Groovy is being used throughout the Java industry, and in most places it’s just acknowledged without comment. Grails, for all its power, feels like an easy way to build traditional Spring/Hibernate web applications, which work really well but are hardly sexy.

It’s therefore not surprising that the potential of Groovy and Grails is often underestimated. I have no idea what Pivotal was thinking, and the public statements about them have been uniformly positive (again, not a big surprise given the people involved), but I find it easy to believe Groovy and Grails were underrated yet again.

Many people will now write many posts demonstrating, yet again, how powerful Groovy is and how easy it is for Java developers to learn. The Grails web site already has dozens of success stories. I’m not going to try to add to that, other than to say I love working with both technologies and they’ve completely changed my life.

I want to mention something else. I’ve been in the IT industry for over 20 years. I was in the engineering community for a dozen years before that. I would hold up my academic background against anybody’s. From all those experiences, I’ve known geniuses and incredibly hard workers, and communities who are friendly, hostile, and everything in between.

I’m here to tell you that the Groovy and Grails core teams members are among the brightest people I’ve ever met, but they’re also successful because they’re wonderful individuals to be around. In an industry often marred by what I like to call “boys behaving badly,” I’ve never heard a negative word about anyone involved in Groovy and Grails. That attitude starts at the top, with great people like Graeme and Guillaume, and I feel privileged to know and work with them, however tangentially.

Look, community matters. It makes the difference between struggling to accomplish anything and enjoying your job. I teach technical training courses for a living, and you should see the joy in Java developers eyes when they learn both how much they can now do, and — this is important — how newcomers are treated with respect and how their questions are answered without patronizing or humiliating attitudes.

They say it’s hard for companies to find good developers these days. Well, here’s your opportunity. For the price of supporting technologies that will inevitably help your bottom line, you can acquire a team of coders that are among the most accomplished, most dedicated, and most easy to work with that you’ll ever meet.

Pivotal is now out of the picture. This is a great opportunity for a smart company to step in, acquire two fantastic teams of developers, and be a hero to the open source community. Heck, I’d do it myself if I could afford it. Don’t miss this chance. They don’t come along very often.

Spaceships, Elvis, and Groovy inject

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:

(1..20).collect { it * 2 }      // double them all
       .findAll { it % 3 == 0 } // find the doubles divisible by 3
       .sum()                   // add them up

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:

(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

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:

def strings = 'this is a list of strings'.split()
assert strings.class == java.lang.String[]

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.

List strings = 'this is a list of strings'.split()
assert strings.class == java.util.ArrayList

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.

List strings = 'this is a list of strings'.split()
Collections.sort()  // natural sort (alphabetical)
assert strings == ['a', 'is', 'list', 'of', 'strings', 'this']

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.

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

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:

(1..4).inject(0) { result, i ->
    println "$result + $i = ${result + i}"
    result + i

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:

List strings = 'this is a list of strings'.split()
strings.inject('') { prev, curr ->
    println "prev: $prev, curr: $curr"
    assert prev <= curr
    curr  // value of 'prev' during next iteration

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:

List strings = 'this is a list of strings'.split()
strings.inject { prev, curr ->
    println "prev: $prev, curr: $curr"
    assert prev <= curr
    curr  // value of 'prev' during next iteration

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:

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.

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).

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]

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.

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.

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:

List strings = 'this is a list of strings'.split()
strings.sort { s1, s2 -> 
    s1.size() <=> s2.size() ?: s2 <=> s1

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?

Here, finally, is a test based on inject for that sort:

strings.inject { prev, curr ->
    assert prev.size() <= curr.size()
    if (prev.size() == curr.size()) {
        assert prev >= curr

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


The Reason The Internet Was Invented, or, Cat Pictures FTW

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:

String key = new File('flickr_key.txt').text

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:

String endPoint = 'https://api.flickr.com/services/rest?'

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.

def params = [method: 'flickr.photos.search', api_key: key,
    format: 'json', tags: 'cat', nojsoncallback: 1,
    media: 'photos', per_page: 6]

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:

def qs = params.collect { k,v -> "$k=$v" }.join('&')

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.

File f = new File('cats.json')
if (f) f.delete()
f << jsonTxt
println JsonOutput.prettyPrint(jsonTxt)

Here’s a sample from that output:

    "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"

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.

def json = new JsonSlurper().parseText(jsonTxt)
def urls = json.photos.photo.collect { p ->

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.

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()))

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.

1. Okay, that’s a little harsh. Nothing could be as awful as YouTube comments. Or perhaps the correct response to that is, “I didn’t know YouTube supported comments.” If that’s your answer, I SO wish I was you.
2. Come on, stop laughing. I get it: “If you don’t remember what Bing is, just Google it”. Ha ha.
3. What did you expect toURL to convert the string into, a tomato? That would be pretty cool, actually. Now I wish I had that method. Of course, Groovy is an open source project…​
4. Usually it’s cats, but once I got a bunch of tractors, which confused me until I realized they were manufactured by Caterpillar.

SpringOne2GX, Day Minus 3

Yes, that’s a minus sign, because the event in question hasn’t happened yet. This is my first report from the upcoming SpringOne2GX conference, which starts in Dallas, TX next Monday, 9/8/14 (or 8/9/14 for my non-US-based friends). Since there are no talks on the opening day (just an opening keynote and reception), I’m arbitrarily designating that as Day Zero. I’m giving several talks at the conference and I thought I’d comment here on my preparations. I also have a kind of “insider” status, being a member of the No Fluff, Just Stuff conference tour (one of the organizers of SpringOne2GX*) and, as the author of Making Java Groovy, I know a lot of people in the community. That will hopefully give me opportunities to share amusing anecdotes and other non-presentation-based tidbits of information here.

*What is the proper hashtag for the conference? In past years people have recommended #springone2gx, but that’s way too many characters. The value #s12gx seems reasonable, but didn’t seem to catch on. Most people I know used #s2gx, which is probably what I’ll adopt.

Speaking of embarrassing anecdotes, let me give you one right away. Two years ago, after one of my talks at that year’s s2gx conference, Guillaume Laforge and Cedric Champeau came up to me to say hi. Guillaume, who lives near Paris, has an outrageous French accent. Every time I talk to him I keep thinking of this character from the classic movie. So I finally got up the nerve to ask him, “Just once, would you say to me, ‘your mother was a hamster, and your father smelt of elderberries!'”.

He and Cedric both just stared at me like I’d lost my mind. They had no idea what I was talking about. It wasn’t until later I realized that even if they knew Monty Python and the Holy Grail (a minimum requirement for any decent developer), they knew it in French.

Oh well.

This week I’m still polishing (yeah, right, polishing — not writing from scratch, at least as far as you know) my slides. I’m scheduled to give the following talks:

This is an introduction to Grails, combining domain classes (of course, Quest, Task, Knight, and Castle), controllers, services (using the Google geocoder), and more. Experienced Grails developers can comfortably skip it, but newbies will no doubt appreciate the introduction. I plan to add in some architectural discussions, as well as some Hibernate and/or Spring stuff if time allows.

I gave a similar talk a couple years ago, but things have changed significantly since then. As a minimal example, now the default unit testing framework is Spock, rather than the JUnit subclasses we used to use. Everything is annotation based, too. I’ll definitely talk about testing controllers, services, and domain classes (constraints), and plan to do a couple of integration tests as well, and then talk about various plugins, like the Build Test Data plugin and some other functional ones.

As I travel from company to company*, I rarely see the new REST capabilities in Grails 2.3+ being used. Last year Graeme Rocher did a wonderful presentation on them, as well as a brief discussion of the asynchronous capabilities in Grails. I hope to cover much the same (REST) ground, but rather than get into async I’m going to talk about customizing responses, using HAL for hypermedia, and so on.

*My day job is teaching technical training courses in pretty much all areas related to Java, specializing in open source topics like Spring, Hibernate/JPA, Android, Groovy, and Grails. That means I visit somewhere between 30 to 50 companies a year, and while I’m mostly talking to people who don’t know much about Grails yet, I’m always trying to find out what they are using. Between that and the NFJS conferences, I get a decent sense of what is becoming popular in the industry and what isn’t catching on.

As a sample, both Groovy and Grails are still growing at their normal slow, steady pace. Spring Boot is generating a lot of excitement among the more advanced developers, but most Spring users in the field haven’t even heard of it. I imagine this year’s conference will start to change that.

It turns out that Jeff Brown (co-author of DGG2, the Definitive Guide to Grails 2) is giving a talk entitled RESTful Grails 2 at 12:45pm on Tuesday. This is extraordinarily fortunate for me, because that means I can steal (er, reuse) whatever he says. Sweet. 🙂

I gave a similar talk last year, and was just getting ready when Paul King walked into the room. Paul King is one of the Greatest Groovy Experts Ever, and I experienced a flood of Imposter Syndrome as soon as he entered. Fortunately, he didn’t violently disagree with anything I said and was kind enough to share some additional information after it was over. Is it any wonder he is one of my personal heroes?

Another interesting Paul King tidbit: last time I checked, he had more commits to the Groovy code base than anyone, ever. Heck, I just checked and he did six more today.

I’ve updated the talk with new information, which should be fun. The toughest problem I’ll have is not giving away spoilers for the Groovy Puzzlers talk coming later in the conference.

(Go to the puzzlers talk. It’s fun.)

This is a big one for me. The fact that Android applications are now built using Gradle is a big deal for every Android developer, and the Android plugin for Gradle is still evolving at a rapid rate. The new IDE, Android Studio, is also changing all the time. My hope is to give the most up-to-date information on it possible. I’ll show the multi-project build they use by default, add some dependencies, run some tests (using the Robotium plugin), talk about Spring Android, and show some flavors and variants.

Best of all, I expect to try to update Android Studio right before the talk, so I have the latest possible version in the so-called Canary channel. What could possibly go wrong?

This is a revised and extended version of the same talk I gave at the Gr8 conf in Minneapolis in July. Those talks were limited to an hour, and given that lots of speakers were talking about Ratpack*, I decided to focus on Grails for the REST part. Now I should have time for both.

*Dan “Tiger” Woods is giving his Ratpack Web Framework talk at 2:30pm on Tuesday.

Wait, let’s try to improve that:

['Tiger','James','Ickey','Mirk','Sher'].each { nickname ->
    println "Dan '${nickname}' Woods"

Let me know if you have some better suggestions. Also, Lari Hotari is giving a talk on Ratpack and Grails 3.

Since there are no images in this post, here’s a small spoiler from the Groovy Vampires talk. Note the nice subtitle.

Making Java Groovy: Still a better love story than Twilight

If you’re coming to the conference, please drop by and say hi. I hope to write a short blog post every day of the conference, commenting on what talks I attended and which people I spoke to, but that’ll depend on how much last minute “updating” I’ll need to do on my slides.

Responses to “The Closure Of No Return”

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:

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

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:

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

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:

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
    return result

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:

boolean isPrime3(int x) {
    if (x == 2) return true
    int limit = Math.sqrt(x) + 1
    !(2..limit).any { n ->
        x % n == 0

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:

// 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;

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):

boolean isPrime5(int x) {
    int limit = Math.sqrt(x) + 1
    x == 2 || !(2..limit).find { n -> x % n == 0 }

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.)

%d bloggers like this: