Could you provide a small script that demonstrates the issue? For your example, what is the type returned by "cfValues['SpecialKey']"? Is it a list, map or some user-defined type? What is the expected type of "cfValues['SpecialKey']*.name" if you assigned it to a temporary variable?
Determining the aggregate type when applying the * operator has had some fixes to it. If you supply special metadata to help type on of the subexpressions, can you say what keys you are using or are you using a type-checker extension? ________________________________ From: Jonny <jonny...@apache.org> Sent: Monday, June 16, 2025 5:18 PM To: dev@groovy.apache.org <dev@groovy.apache.org> Subject: [EXT] Static Type Checker Changes for Closure Parameters in 4.0.19 onward External Email: Use caution with links and attachments. Cross-posting to the mailing list from Slack<https://urldefense.com/v3/__https://groovy-community.slack.com/archives/C2NEFCM55/p1750110654202509__;!!GFN0sa3rsbfR8OLyAw!YZyV0o3N2Xf4XCeQ_ksNawkcRNlQN2eVfW0Z6J8my3GZOuFXbV_v5_Bp1S1rbqvW8x3WewID0n1WMO6C9zhl6V9g$>. I'm trying to debug an issue with the static type checker and closure method parameters. It seems like in Groovy 4.0.19, something changed that has broken type checking for statements like: cfValues['SpecialKey']*.name.collect {it.toUpperCase()} Some context: cfValues is a binding variable that I provide custom type information for via a ClassCodeExpressionTransformer. In this case, the static type checker seems to know that cfValues['SpecialKey'] returns a value of the expected type which, in turn, has a name property that is a String. Statements like: cfValues['SpecialKey']*.name*.toUpperCase() compile just fine. But from Groovy 4.0.19 onward, the static type checker only seems to think that the it Closure parameter is an Object, not a String. I've been poring over the diff, the changelog<https://urldefense.com/v3/__https://groovy-lang.org/changelogs/changelog-4.0.19.html__;!!GFN0sa3rsbfR8OLyAw!YZyV0o3N2Xf4XCeQ_ksNawkcRNlQN2eVfW0Z6J8my3GZOuFXbV_v5_Bp1S1rbqvW8x3WewID0n1WMO6C9xN9UByT$>, and stepping through the debugger to figure out what changed, but I haven't been able to fathom it out. Does this ring a bell for anyone? Thanks for any pointers. Best, Jonny Carter
