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.
Jason
Sensitivity: Internal
From: Winnebeck, Jason <jason.winneb...@windstream.com>
Sent: Tuesday, August 18, 2020 12:22 AM
To: users@groovy.apache.org
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 DELEGATE_FIRST
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!"
something.with(closure)
}
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?
Thanks,
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.
