Over a million developers have joined DZone.

Groovy: Resolve Strategies

· Java Zone

Discover how AppDynamics steps in to upgrade your performance game and prevent your enterprise from these top 10 Java performance problems, brought to you in partnership with AppDynamics.

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

The Java Zone is brought to you in partnership with AppDynamics. AppDynamics helps you gain the fundamentals behind application performance, and implement best practices so you can proactively analyze and act on performance problems as they arise, and more specifically with your Java applications. Start a Free Trial.

Topics:

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

{{ parent.tldr }}

{{ parent.urlSource.name }}