groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <>
Subject RE: Groovy 3 OWNER_FIRST closure passed to method with resolve strategy DELEGATE_FIRST
Date Tue, 18 Aug 2020 15:02:43 GMT
I did some research with Groovy 2.5 that I happened to have installed on path... It seems that
CompileStatic bakes in the resolve strategy at the time the closure is created. So my 2.4
project, assuming 2.5 works the same as 2.4, is operating as OWNER_FIRST, even though it's
passed to with (unless the closure was compiled in dynamic mode).

It seems for me, the proper solution then is to not use "with" but instead create a new variation
of "with" that works with OWNER_FIRST and call that instead. It seems also that this message
might be better as a warning than an error, or to have a flag have it be a warning, since
it looks like it can work as the old code in runtime, although I agree, any new code written
should not have this pattern because it is so misleading.


Sensitivity: Internal
From: Winnebeck, Jason <>
Sent: Tuesday, August 18, 2020 12:22 AM
Subject: Groovy 3 OWNER_FIRST closure passed to method with resolve strategy DELEGATE_FIRST

I'm upgrading a project from Groovy 2.4.19 to 3.0.5 with 100s of classes almost all @CompileStatic
code on JDK 8. Upon upgrading I get compiler errors about static type checker knowing or not
knowing anymore of objects, which is par for the course for any Groovy upgrade. But most of
the errors I get are this:

Closure parameter with resolve strategy OWNER_FIRST passed to method with resolve strategy

The pattern that I am using is having a method that takes a Closure, and passes it to Object.with:

void run(@DelegatesTo(X) Closure closure) {
  println "I'm running!"

run { println prop }

So I know what OWNER_FIRST and DELEGATE_FIRST mean. And I see that the default in @DelegatesTo
(or no annotation presumably) is OWNER_FIRST, and with clones the closure and sets its resolve
strategy to DELEGATE_FIRST.

I can't find documentation on this message. Does the message being an error imply that the
resolve strategy on a closure is "baked in" in CompileStatic? Did that change since 2.4? What
is the best practice solution?

Other notes:

  1.  I build with IDEA and the default 700mb heap was not enough to build, I needed 5GB heap
to build without OutOfMemoryError is that expected?
  2.  I'm trying to upgrade from 2.4.19 because I encountered a bug in static compile, in
an expression x.value = someEnum, there is x.setValue(boolean) and x.setValue(String). 90%
of the time the static compiler picks the setValue(String) for all such call sites in a build,
10% of the time it picks setValue(boolean) for all such call sites. I didn't receive any compiler
errors on that expression as I'd expect it to be ambiguous (or at least pick same each time),
is that expected to fail compile in Groovy 3?


Jason Winnebeck

Sensitivity: Internal
This email message and any attachments are for the sole use of the intended recipient(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all copies of the
original message and any attachments.

View raw message