Expression-oriented programming in Groovy: transpose() is zip()

The term "expression-oriented programming", as mentioned in these blog posts, resonated with me:

• http://richardminerich.com/2012/07/functional-programming-is-dead-long-live-expression-oriented-programming/
• http://joelmccracken.github.io/entries/the-rise-of-expression-oriented-programming/

Groovy is by no means a purely functional language, but it does include a lot of the basics. Moreover, it includes a few other goodies that make it really nice for expression-oriented programming.

Here's a set of posts about some of these constructs.

One oddity about Groovy's support for functional programming is that Groovy chooses unusual names for some common functions from functional programming.

I believe this is because Groovy chose names from its object-oriented heritage (SmallTalk), rather than from the functional-programming canon.

For example:

• map() is called collect() in Groovy
• fold() or reduce() are inject() in Groovy
• filter() is findAll() in Groovy

One of the most obscurely-named such methods in Groovy is transpose(), and as a result it's easily overlooked.

A very useful function in functional programming languages such as Haskell and Scala is zip(), which is used to combine corresponding elements from more than one collection.

Suppose we have two lists, a and b, containing numbers. And we want to find the maximum from each pair of corresponding numbers from these lists.

Groovy provides a lot of nice methods for working with a single list. But faced with two lists to be traversed together, many would revert to old Java-style code:

def a = [5, 10, 15, 20, 25]
def b = [20, 16, 12, 8, 4]

def r1 = []
for (i in 0..<a.size()) {
  r1[i] = Math.max(a[i], b[i])
}

assert r1 == [20, 16, 15, 20, 25]

We could try to use one of Groovy's iteration methods, eachWithIndex(), but the result is hardly better:

def r2 = []
a.eachWithIndex {v, i ->
  r2[i] = Math.max(v, b[i])
}

assert r2 == [20, 16, 15, 20, 25]

The answer is to use transpose():

def r3 = [a, b].transpose().collect {v, w -> Math.max(v, w)}

assert r3 == [20, 16, 15, 20, 25]

It's a little tricky until you get the hang of it: transpose is called on a list of lists, and it returns a new list of lists. Each list in the new list contains all of the elements at the same position in the original lists.

Actually, for built-in methods like max() that Groovy defines on collections, we can use the spread operator:

def r4 = [a, b].transpose()*.max()

assert r4 == [20, 16, 15, 20, 25]

Suppose instead of taking the max of two items we wanted the sum:

def r5 = [a, b].transpose()*.sum()

assert r5 == [25, 26, 27, 28, 29]

transpose() is also nice because it generalizes nicely beyond the case of just two lists.

def c = [3, 6, 9, 12, 15]

def r6 = [a, b, c].transpose()*.sum()

assert r6 == [28, 32, 36, 40, 44]

Of course, our lists do not have to be of the same type.

Here's an example where one list contains strings and another lengths, and we want to pad each string to the corresponding length:

def strings = ["one", "two", "three", "four", "five", "six"]
def lens = [1, 2, 3, 4, 5, 6]
def r7 = [strings, lens].transpose().collect {item, len -> item.padRight(len)}

assert r7 == ["one", "two", "three", "four", "five ", "six   "]

Java 8 added lambdas and the Streams API, which permit many functional idioms. A zip() method was originally included in the Java 8 SDK previews, but unfortunately was removed before release. Never mind, we have it in Groovy!

So despite its unconventional name, keep transpose() in mind when working with lists. And if you have any interesting usages yourself, post them (or links) in the comments!

Gradle version selector incompatability

We had some interesting issues with Gradle this week.

We build a number of internal projects with Gradle, and some of these projects have interdependencies. The dependency graph of our internal projects extends to several levels.

To illustrate, this diagram shows three projects, with "server" depending on "common", and "client" depending on "server".

For internal dependencies, we use Gradle's "changing module" version selectors: "latest.integration" and "latest.release".

The problem occurred because Gradle 2.3 changed the way these version selectors are written to a published pom.xml dependency section.

Prior versions wrote the version selectors "as-is", e.g. "latest.integration". I believe that this convention originated with Ivy. But this is not a valid Maven version. So Gradle 2.3 changed to write a valid Maven version such as "LATEST" or "RELEASE".

A great post explaining the options available with Maven, and some of the pros and cons, is this on one StackOverflow.

Generally speaking, it's best to use specific version numbers in dependencies for released artifacts, for repeatable builds. But it's also desirable to have changing or dynamic dependencies for snapshot or integration builds, for continuous integration and testing.

The problem is that older versions of Gradle don't understand these "new" values ("LATEST" and "RELEASE").

Let's show this using the sample projects above. For the purpose of this illustration, we'll use a common init.gradle shared by each project, with contents:

def homeDir = System.getProperty("user.home")
def repoUrl = "file:///$homeDir/tmp/repo"

allprojects {
  apply plugin: "java"
  apply plugin: "maven"

  group = "example"

  uploadArchives {
    repositories {
      mavenDeployer {
        repository(url: repoUrl)
      }
    }
  }

  repositories {
    maven {
      url repoUrl
    }
  }
}

We'll use this init.gradle for every build in these examples, using this alias:

alias mygradle="./gradlew -I../init.gradle"

For the "common" project, we'll have these files:

➜ common git:(master) ✗ tree
.
├── build.gradle
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
└── src
    └── main
        └── java
            └── example
                └── Common.java

In build.gradle we have:

wrapper {
  gradleVersion = "2.2.1"
}

version = "01.00"

We can build "common" like this:

➜  common git:(master) ✗ mygradle uploadArchives
:compileJava
:processResources UP-TO-DATE
:classes
:jar
:uploadArchives
Uploading: example/common/01.00/common-01.00.jar to repository remote at file:////Users/jhurst/tmp/repo
Transferring 1K from remote
Uploaded 1K

BUILD SUCCESSFUL

The generated pom.xml is not very interesting:

<project 
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" 
  xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>example</groupId>
  <artifactId>common</artifactId>
  <version>01.00</version>
</project>

Now we look at "server". The files are:

 
➜  server git:(master) ✗ tree 
. 
├── build.gradle 
├── gradle 
│   └── wrapper 
│       ├── gradle-wrapper.jar 
│       └── gradle-wrapper.properties 
├── gradlew 
├── gradlew.bat 
└── src 
    └── main 
        └── java 
            └── example 
                └── Server.java 

The server project uses Gradle 2.4, and declares a dependency on "common" in its build.gradle:

 
wrapper { 
  gradleVersion = "2.4" 
} 
 
dependencies { 
  compile "example:common:latest.integration" 
} 
 
version = "01.00" 

We build "server":

 
➜  server git:(master) ✗ mygradle uploadArchives 
:compileJava UP-TO-DATE 
:processResources UP-TO-DATE 
:classes UP-TO-DATE 
:jar UP-TO-DATE 
:uploadArchives 
 
BUILD SUCCESSFUL 

Now we have a dependency in the generated pom.xml:

 
<project 
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" 
  xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>example</groupId>
  <artifactId>server</artifactId>
  <version>01.00</version>
  <dependencies>
    <dependency>
      <groupId>example</groupId>
      <artifactId>common</artifactId>
      <version>LATEST</version>
      <scope>compile</scope>
    </dependency>
  </dependencies>
</project>

This dependency is specified using the new, Maven-compatible version selector.

Now we go to "client":

 
➜  client git:(master) ✗ tree 
. 
├── build.gradle 
├── gradle 
│   └── wrapper 
│       ├── gradle-wrapper.jar 
│       └── gradle-wrapper.properties 
├── gradlew 
├── gradlew.bat 
└── src 
    └── main 
        └── java 
            └── example 
                └── Client.java 

The client project uses Gradle 2.2.1, and declares a dependency on "server" in its build.gradle:

 
wrapper { 
  gradleVersion = "2.2.1" 
} 
 
dependencies { 
  compile "example:server:latest.integration" 
} 
 
version = "01.00" 

We attempt to build "client":

 
➜  client git:(master) ✗ mygradle uploadArchives 
:compileJava 
 
FAILURE: Build failed with an exception. 
 
* What went wrong: 
Could not resolve all dependencies for configuration ':compile'. 
> Could not find example:common:LATEST. 
  Searched in the following locations: 
      file:/Users/jhurst/tmp/repo/example/common/LATEST/common-LATEST.pom 
      file:/Users/jhurst/tmp/repo/example/common/LATEST/common-LATEST.jar 
  Required by: 
      example:client:01.00 > example:server:01.00 
 
* Try: 
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. 
 
BUILD FAILED 

The problem is that Gradle 2.2.1 does not correctly interpret "LATEST" as a changing module version selector.

It's easily fixed - we simply upgrade "client" to Gradle 2.3 or later.

You might think this is a really trivial problem. It is, once it's clear what is going on. We found it a bit confusing at first because we didn't know where the "LATEST" string in the dependency error message was coming from.

There is a further difficulty caused by this change if you use Groovy's Grapes feature in Groovy scripts to fetch dependencies. Grapes uses Ivy to resolve dependencies, and it does not understand this LATEST/RELEASE syntax in POM files either.

To show this, let's use a ivysettings.xml file as follows:

 
<ivysettings>
  <resolvers>
    <ibiblio 
      name="downloadGrapes" 
      m2compatible="true" 
      root="file:///Users/jhurst/tmp/repo"/>
  </resolvers>
  <settings defaultResolver="downloadGrapes"/>
</ivysettings>

We configure Groovy to use this using the grape.config system property:

 
export JAVA_OPTS="-Dgrape.config=$PWD/ivysettings.xml" 

Let's have a Groovy script that has a dependency on the "common" module:

 
@Grab("example:common:01.00") 
import example.Common 
 
println Common.simpleName 

When we run this, it fetches the dependency and runs successfully:

 
➜  groovy git:(master) ✗ groovy ./grabcommon.groovy 
Common 

Let's try another Groovy script that has a dependency on "server" instead:

 
@Grab("example:server:01.00") 
import example.Server 
 
println Server.simpleName 

When we run this, we get a similar failure to that with Gradle earlier:

 
➜  groovy git:(master) ✗ groovy ./grabserver.groovy 
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: 
General error during conversion: Error grabbing Grapes -- 
  [unresolved dependency: example#common;LATEST: not found] 
 
java.lang.RuntimeException: Error grabbing Grapes -- 
  [unresolved dependency: example#common;LATEST: not found] 
... 

This one is not so easy to solve.

Gradle originally used Ivy's dependency resolution code, but then switched to using its own code. Groovy's Grapes feature still uses Ivy.

We need either to improve Ivy to support this syntax in POM files, or else perhaps it would be better to get Groovy Grapes to use Gradle's dependency resolution code instead of Ivy. But given that Grapes is configured using an ivysettings.xml, and Gradle does not provide any analogous way to tell a Groovy script where to look for dependencies, it is not obvious how we would switch Groovy to use Gradle's code. Besides, Groovy needs to continue to support ivysettings.xml and all Ivy features, for backwards compatibility.

A colleague of mine pointed out that one solution is to use the long form of @Grab, with transitive = false, like this:

@Grab(group = "example", module = "server", version = "01.00", transitive = false)
@Grab("example:common:01.00")
import example.Common
import example.Server

println Server.simpleName
println Common.simpleName

This works, but it excludes all of the transitive dependencies. If you have a lot of third party dependencies and need this exclusion only for your local modules, it's not that great.

Looking at Elixir

The Pragmatic Programmers had a big impact on me with the PickAxe book introducing Ruby, among many other things.

So when Dave Thomas gets excited about a new language, I get excited too. His new book "Programming Elixir", is in a quite different style from the PickAxe, much briefer, just tries to give an overview and a taste. This too is quite appealing. In this day of Google and Stack Overflow, we don't need hardcopy reference materials. (On the other hand, when I look at how little work I can get done these days without consulting Google, I have to admit those printed references must have actually been quite useful!)

Anyway, I've been working through this new book and Elixir a little, while on vacation. I'm no expert on Elixir, Erlang, Haskell, functional programming, or pretty much anything. Nevertheless I thought I might put a few of my impressions. Besides, this blog hasn't had enough activity, and with New Year's Resolutions and everything...

Here are the things that struck me.

Aesthetic.

It looks and feels a bit like Haskell, but ugly.

Perhaps not a fair comparison, because I feel that Haskell is the most beautiful programming language I have seen.

Length of a list, in Haskell:

len [] = 0
len (h:t) = 1 + len t

In Elixir:

def len([]), do: 0
def len([_|t]), do: 1 + length(t)

Extra 'def' keyword required, and what's with that ", do:=" gunk? Isn't Haskell's definition as clear and minimal as conceivably possible?

Another example: 'map'. In Haskell:

map _ [] = []
map f (h:t) = f h : map f t

In Elixir:

def map(_, []), do: []
def map(f, [h|t]), do: [f.(h) | map(f, t)]

It's the same, just with extra punctuation.

Laziness.

It seems like Elixir supports laziness only when explicitly using the Stream module. Functions cannot be defined recursively using list constructors to return infinite lists.

In Haskell:

repeat x = x : repeat x

In Elixir, maybe:

def repeat(v), do: Stream.iterate(v, fn _ -> v end)

It's an awkward definition because of the need to provide an inline function returning the constant value. But worse, the return type is not the same as a list.

For example, in Haskell we can define take:

take n (h:t) = if n==0 then [] else h : take (n-1) t

And then use it with 'repeat':

take 3 $ repeat 10

But with Elixir, the list definition of 'take':

def take(0, _), do: []
def take(n, [h|t]), do: [h|take(n-1, t)]

Does not work with streams:

iex(14)> Haskell.take(3, Haskell.repeat(1))
** (FunctionClauseError) no function clause matching in Haskell.take/2
  haskelllib.exs:55: Haskell.take(3, #Function<3 .80570171="" in="" stream.iterate="">)
  erl_eval.erl:569: :erl_eval.do_apply/6
  src/elixir.erl:138: :elixir.eval_forms/3

Although the builtin 'Enum.take' does work:

Enum.take(Haskell.repeat(1), 3)

But this returns a list, not a stream.

OK, for 'take' it may often be fine to create a full list rather than a lazy list. But how about 'map'?

The list version of 'map' can be defined:

def map(_, []), do: []
def map(f, [h|t]), do: [f.(h) | map(f, t)]

But this version cannot be used with streams, and we really do want lazy 'map' with lazy streams.

To be fair, this is probably a conscious decision in Elixir to separate lists and streams, just as it is in Scala. I guess that there is a fair tradeoff to be made about laziness, e.g. see this blog.

Function parameter ordering.

You might have noticed that in the above definitions of 'take', the standard Elixir version defines the arguments in a different order from the Haskell version.

The reason is that in Elixir, for the pipe operator '|>' to work, a function must take a list as its first parameter.

[1,2,3,4,5] |> Enum.take(2)

But it seems to me that it's better to give lists as the last argument, as in Haskell, for the purpose of currying:

f = filter even
f [1,2,3,4,5,6,7]

It is perhaps telling that in "Programming Elixir", the word "curry" does not occur. (Nor does "partial" in the sense of partially applied function.)

Having said that, I have to admit that the pipe operator looks appealing, largely due to its nice left-to-right reading. The example in the Prag book is:

filing = DB.find_customers
|> Orders.for_customers
|> sales_tax(2013)
|> prepare_filing

I suppose that in Haskell this would look something like this:

filing = prepare_filing $ sales_tax 2013 $ Orders_for_customers $ DB_find_customers

The right-to-left reading of Haskell is one of the least-appealing aspects of it for me, sometimes.

Summary

For me, for learning Functional Programming, I think I'll stick with Haskell. It seems like a nicer language and there are some good resources.

On the other hand, if you are on the Erlang platform, or want to be, maybe because of the nice concurrency or high availability features, then you might find Elixir an attractive alternative to (or complement to) the Erlang language.

Bad math in BBC

In the BBC Magazine story Amanda Knox and bad math in court, there is an explanation of probability relating to evidence in a legal trial.

The article quotes mathematician Coralie Colmez, co-author of "Math on Trial: How numbers get used and abused in the courtroom". Well, I hope they misquoted her. The math presented in the article does not appear to add up.

The example given is:

"You do a first test and obtain nine heads and one tail... The probability that the coin is fair given this outcome is about 8%, [and the probability] that it is biased, about 92%. Pretty convincing, but not enough to convict your coin of being biased beyond a reasonable doubt," Colmez says.

Technically in this situation we talk about the probability that a fair coin will give a particular outcome. We can calculate the chance of a fair coin giving nine or more heads (or zero or one tails), using the binomial distribution.

In Excel we can use =BINOMDIST(1,10,0.5,TRUE). In the statistical program R the formula is pbinom(1,10,0.5).

The answer is 0.01074219, or about 1%. I don't know where the 8% quoted in the article comes from.

The more subtle problem is that the chance of a fair coin producing a result is not the same as the chance of the coin being fair given a result. This is what the article seems to imply, and is a common mistake.

The theory we need for this kind of statement is Bayes' Theorem, which deals with conditional probabilities:

P(A|B) = P(B|A) P(A) / P(B)

Where P(A|B) means "Probability of A, given B".

To know the probability of this particular coin being fair after an experiment we'd need to know more information about the whole population of coins.

Ant Profiling

In my new job at Assurity Consulting I've been looking at some large builds. Some that take 6 hours or more to run in the Continuous Integration Server. There's a fairly random mix of Ant, Maven and good old shell. The last few days I spent some time diving into the details of a fairly large Ant build.

I've been using a combination of three techniques to analyze where the time is being spent in this build:

1. Analysis by inspection.
2. Analysis of "ant -d" output.
3. Ant Profiler.

There are a number of files and many tasks and targets in this build, and I haven't been able to walk through the entire thing yet. But by browsing through "interesting" parts, I have been able to find out some significant things about the build.

For example, the build makes extensive use of <antcall>. Sometimes people use <antcall> when they don't understand the correct usage of "depends" on Ant targets. In this build, many of the <antcall> usages would be more appropriately done with <macrodef>. <antcall> is inefficient to use on targets within the same build file, because it reparses and copies properties. Please learn to use <macrodef> with Ant. It is your friend.

To extract some data about the Ant build as a whole, I ran it with "ant -d". On this particular build, it generates 600,000 lines of output. Again, a lot of detail.

With some shell piping we can see potential areas of duplication, or work being repeated:

ant -d >ant.debug.out 
sort ant.debug.out | uniq -c | sort -nr | head

For example, we can see whether certain Java source files are compiled more than once during the build:

egrep "^ *\\[javac\\]" ant.debug.out | sort | uniq -c | sort -nr | less

In this case I found that some classes are compiled twice, three, four or five times. Unfortunately, not enough classes to make a large difference to the build time, but still ...

Finally, I found a great Ant profiler called antro. This profiler is really neat. It is completely non-invasive. It uses the Ant listeners feature, and can be run like this to analyze a build:

ant -listener ru.jkff.antro.ProfileListener -lib ~/antro/antro.jar build.xml

This generates a JSON file, which can then be loaded into the profiler's GUI. The GUI is run simply with:

java -jar antro.jar

What could be simpler?

It provides a tree view of the build times, where you can drill down into any node and explore the detail. Using this tool it's easy to get a bird's eye view of the build time breakdown, as well as drill into areas of interest. For example, I was able to assess the overhead of <antcall> by looking at some of those nodes. Unfortunately, there seems to be no way to see the total number or overhead for a single task type such as <antcall> across the whole build. I was able to find the total number of <antcall>s (not the times though) from the "ant -d" output. This allowed me to estimate the total time overhead of <antcall> for this build.

Git and SVN on OSX 10.8 - is this the best way?

Don't get me started on Apple. I bought my first Mac a few weeks ago, and I'm still trying to figure out why. They are pretty, but they are also pretty frustrating. Other than the hardware compatability problems with Linux, which may actually have driven me crazy, Ubuntu is a much better-designed system.

For one thing, Apple seems determined to gradually eliminate standard UNIX software from this platform. Which kind of defeats the whole point I bought the thing -- I wanted a reliable UNIX-based system. I realize that Apple could not give a toss about UNIX geeks, having a very lucrative mass market of schmucks to serve, but still that doesn't console me much. One day I will post a long list of frustrations I have found since starting with OSX.

Today I just want to post how I got something working, in case I need it later. In Ubuntu, if I want to use Git and SVN, I have to type something like this:

sudo apt-get install subversion
sudo apt-get install git-core

Something like that. Also maybe

sudo apt-get install git-svn

I don't remember. Actually, I don't have to remember, or type it, because bash on Ubuntu has completions. There's nothing to it.

In OSX, there is no standard package management system. (Let alone bash completions.) There are a variety of independent efforts (Mac Ports, Homebrew, Fink), and they all hate each other. You pick one of those and hope for the best.

Except Apple keeps trying to break them.

The worst thing I have done with OSX so far is upgrading to 10.8. This was a stupid mistake, because 10.8 does not contain any useful features, but instead breaks things that I had come to depend on. I did it because I thought it was supposed to fix fullscreen mode with multiple monitors, which was already broken. It is still broken.

Prior to 10.8 I was able to get Git and SVN working using Homebrew. After 10.8 I get compilation errors.

So instead I installed SVN using the brain-dead Windows method of click-till-you-die installation from a binary DMG file from git-scm.com. And I installed Git similarly by clicking and clicking and clicking with a binary PKG file from WANDisco. This was fine, for independent Git and SVN operation. But Git-SVN did not work. I got

Can't locate SVN/Core.pm in @INC

because the Git Perl code is in one place, and the SVN Perl code is somewhere completely different.

Only the wise and benevolent creator can tell why these things need to talk to each other using Perl. It probably comes from Git being implemented using every UNIX hack tool under the sun.

I got them to work, apparently, by doing this:

sudo ln -s /opt/subversion/lib/svn-perl/auto /usr/local/git/lib/perl5/site_perl/auto
sudo ln -s /opt/subversion/lib/svn-perl/SVN /usr/local/git/lib/perl5/site_perl/SVN

What a hack! And only works because there was no auto/ directory there already! This is gonna break, I know it! Hopefully the Homebrew version will be working again by then.

Give me Ubuntu for this sort of thing any day. Shit, even give me an RPM-based system, I'll be happy with that.

Groovy AST transform gotcha

I'm a big fan of Groovy's AST transforms. Lately I've been using @Lazy in a lot of my code, because I love a declarative or functional style of programming, and @Lazy lets me do that really efficiently and concisely with Groovy. I hope that my colleagues agree!

We got caught by an interesting trap using a couple of other transforms recently: @EqualsAndHashCode and @Immutable. We like to use @EqualsAndHashCode to generate equals() and hashCode() for entity classes in our domain model. We use the 'includes' attribute to include only the primary key properties in the equals() comparison, like this:

@EqualsAndHashCode(includes = "id")
class Foo {
  String id
  String description
}

For this class, and its corresponding database table, the 'id' property is the key. Equality is not done by Java object equality, or by full value equality, but by comparing the entities' primary keys:

assert new Foo(id: "1", description: "cat") == 
       new Foo(id: "1", description: "dog")

This has important effects when storing these kinds of objects in collections.

Be careful mixing AST transform annotations though! We added @Immutable to some of our domain classes, like this:

@Immutable
@EqualsAndHashCode(includes = "id")
class Foo {
  String id
  String description
}

and got a surprising result:

assert new Foo(id: "1", description: "cat") != 
       new Foo(id: "1", description: "dog")

The reason is the order of the annotations. If we reverse them, it works correctly:

@EqualsAndHashCode(includes = "id")
@Immutable
class Foo {
  String id
  String description
}

assert new Foo(id: "1", description: "cat") == 
       new Foo(id: "1", description: "dog")

So what happens? The doc for @Immutable says:

The @Immutable annotation instructs the compiler to execute an AST transformation which adds the necessary getters, constructors, equals, hashCode and other helper methods that are typically written when creating immutable classes with the defined properties.

Later on, in more detail:

Default equals, hashCode and toString methods are provided based on the property values. Though not normally required, you may write your own implementations of these methods. For equals and hashCode, if you do write your own method, it is up to you to obey the general contract for equals methods and supply a corresponding matching hashCode method. [...]

So, I'm guessing that if we put @Immutable first, then @EqualsAndHashCode hasn't yet had a chance to do its magic, and @Immutable adds its default equals() etc, not the ones we want. But if we put @EqualsAndHashCode first, then its equals() etc methods are there for @Immutable to see, and we get the behavior we want.

Thus, problem solved, for now. But it does make one wonder a little about the interactions of all of these transforms and other annotations. We've been using Groovy AST transform annotations together with JPA annotations with no known problems to date, and I hope it continues that way.