Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Groovy: Resolve Strategies

DZone's Guide to

Groovy: Resolve Strategies

· Java Zone ·
Free Resource

Get the Edge with a Professional Java IDE. 30-day free trial.

A few weeks ago I had to deal with an interesting bug in one of my DSLs. I had a simple builder overriding propertyMissing and saving all missed properties to map inside the builder:

class SampleBuilder {

private savedObjects = [:]

void propertyMissing(String name, value){
savedObjects[name] = value
}

void printSavedObjects(){
println 'Saved Objects:'
savedObjects.each {
println "${it.key} = ${it.value}"
}
}

static build(Closure c){
def builder = new SampleBuilder()
c.delegate = builder
c()
builder
}
}

I always used that builder inside another class:

class Application {
static void main(String[] args){
def res = SampleBuilder.build {
name1 = 'value1'
name2 = 'value2'
}
res.printSavedObjects()
}
}

The output of the this chunk of code is:

Saved Objects:
name1 = value1
name2 = value2

But what will happen if I use my SampleBuilder in a groovy script?

def res = SampleBuilder.build {
name1 = 'value1'
name2 = 'value2'
}
res.printSavedObjects()

No objects will be saved in that map:

Saved Objects:

It may look weird but if you think about it a bit more it kind of makes sense. To understand why does it happen we need to know how Groovy resolves all missing methods and properties.

Groovy tries to find it by looking in the delegate of the closure or the owner of the closure or using both. You can also specify to use none of them and use Closure’s meta class to resolve missing methods and properties.

These are descriptions of all strategies from http://groovy.codehaus.org/api/groovy/lang/Closure.html:

  • DELEGATE_FIRST. With this resolveStrategy set the closure will attempt to resolve property references to the delegate first.

  • DELEGATE_ONLY. With this resolveStrategy set the closure will attempt to resolve property references to the delegate first.

  • OWNER_FIRST.With this resolveStrategy set the closure will attempt to resolve property references to the owner first

  • OWNER_ONLY. With this resolveStrategy set the closure will resolve property references to the owner only and not call the delegate at all.

  • TO_SELF. With this resolveStrategy set the closure will resolve property references to itself and go through the usual MetaClass look-up process.

OWNER_FIRST is a default strategy used by Groovy.

Let’s look one more time at our SampleBuilder. Why does it behave differently inside a class and inside a groovy script? First of all, let’s look at the way it works inside a class. As the default strategy is OWNER_FIRST it tries to find a missed property in Application class. It can’t find it and that is why it uses delegate property to resolve it. But in a groovy script you can always define global properties using this syntax:

key = ‘value’

Because all our properties are resolved by owner our delegate won’t be invoked. To make it work we just need to change the resolve strategy of our closure to DELEGATE_FIRST:

def builder = new SampleBuilder()
c.delegate = builder
c.resolveStrategy = Closure.DELEGATE_FIRST
c()
builder

If you run that groovy script again you will see what you would have expected to see in the first place:

Saved Objects:
name1 = value1
name2 = value2

From http://victorsavkin.com/post/4135607663/groovy-resolve-strategies

Get the Java IDE that understands code & makes developing enjoyable. Level up your code with IntelliJ IDEA. Download the free trial.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}