ad-hockery: /ad·hok'@r·ee/, n.
Gratuitous assumptions... which lead to the appearance of semi-intelligent behavior but are in fact entirely arbitrary. Jargon File

Articles tagged ‘groovy’

Closures and field visibility

I find Groovy Closures can sometimes behave in ways that, once I think about it, make perfect sense but initially seem surprising. One example of this is the fact that closures declared in a parent class cannot “see” private fields of that class when run in the context of a child class.

Read more…

@CompileStatic and polymorphic method dispatch

I’m a big fan of Groovy’s @CompileStatic feature – so much so that I’ve updated the Groovy class template in IntelliJ IDEA to use it by default. I should stress I don’t do this because I believe non-statically compiled Groovy to be slow – it isn’t.

Recently Peter Ledbrook reminded me of one drawback which is that method dispatch is statically bound when using @CompileStatic like it is in Java. This means that the behavior of calling polymorphic methods can change when argument types are not known at compile time.

Read more…

Enabling Groovy’s “invokedynamic” support in Gradle

I posted previously about configuring a Gradle project to ensure that only the indy version of Groovy (that is the variant that supports Java 7’s invokedynamic bytecode instruction) is included in the dependency graph. However, just including that version of the Groovy jar is not enough to make your Groovy code compile in such a way that it uses invokedynamic.

Read more…

Groovy gotchas: overloading the assignment operator


I reported this issue as GROOVY-6084 and it has been fixed as of Groovy 2.4.0-beta-4. I’m keeping the blog post here for historical interest.

When assigning to a property of an object in Groovy using the assignment operator = Groovy will look for a bean property style setter method. For example = y is equivalent to x.setFoo(y). Or is it?

Since meta-methods can be overloaded with different parameter types what will be printed to sysout if we run this script? (Remember that Groovy - unlike Java - dispatches to the most specific applicable method signature).

Object.metaClass.with {
    setFoo = {
        println "setFoo(Object)"
    setFoo = { String s ->
        println "setFoo(String)"

def o = new Object()
o.setFoo(o) = "foo" = o
Read more…

Groovy gotcha: for loops and closure scope

You probably know that Groovy closures retain information about the scope in which they were created. The closure body can refer to values that were in scope where the closure was declared. There is a gotcha here that has bitten me a few times, though. That’s when closures are created in a for loop.

Consider this example.

def fns = []
for (i in (1..5)) {
    fns << {->
        println i
fns.each { it() }

What will get printed to sysout? Give up? You can run the script on Groovy Web Console. The output is this:

Read more…

Groovy & the public keyword

One of the first things you learn in Groovy is that unlike Java public is the default scope for properties and methods declared on classes. Most developers get into the habit of simply omitting the public keyword everywhere. But, is there any situation where it’s the right thing to use? Actually, yes.

Read more…

Derived values in Spock where tables

When using where blocks in Spock there are two forms; assigning iterable values to a variable, e.g. crew << ['Mal', 'Kaylee', 'Jayne'] or using a datatable. In the first form I always knew you could use assigned values, for example:

crew << ['Mal', 'Kaylee', 'Jayne']
nameLength = crew.length()

Note the assignment operator used rather than the left shift on the second line there.

Read more…

Spock Killer Features: The “old” method

I use Spock almost exclusively to test Groovy or Java code these days. It’s got some fantastic features that other test frameworks don’t have. Some of them aren’t that well known or documented, though.

The old method is possibly my favourite Spock feature. It’s a simple thing but really enhances test legibility. It’s also great for wowing developers new to Spock because it looks like black magic at first glance.

Read more…

Why do Strings behave like a Collection?

Mostly I love Groovy but every now and then some behaviour gets on my nerves. For example, why do the iterator methods on String behave as though it was a collections of characters rather than an Object? If I define a method with a dynamic-typed parameter like:

void printNames(names) {
    names.each {
        println it

Passing a collection of Strings results in each String being printed. Passing a single String results in each character of the String being printed separately. I would have thought that the Object behaviour was a more appropriate default here (iterators on Object are called once passing the object itself). After all the .chars property is available if you really want to represent a String as a collection of characters.

Read more…

Web Statistics