> Thanks again for your thoughtful response. Comments inline.
Thanks for the reply and all of the hard work/fixes. I saw you got
that ticket closed out yesterday, thanks :).
> Things like these:
>
> ```
> log."$level”(msg)
> log.invokeMethod('info', [msg] as Object[])
> ```
> Have the same problem in Groovy 5. They show as
> org.codehaus.groovy.reflection.CachedMethod.invoke instead of the real
> call.
Ah, yeah, I thought I might have not fully understood Jochen’s
comment. Yeah, I can see how and why those types of invocations would
expose the reflective nature of their invocation. It makes sense.
Since they are using the `metaClass` API and it's legitimate
user-facing mechanism expressly intended for reflective invocation and
makes sense to expose that as the callsite/exposed callstack frame
(though, I could see how some minor internals clean-up code be a
nice-to-have).
It was really weird when _every_ call, even plain ones, was being
denoted as a JDK internal reflection invocation when I knew for a fact
they couldn't all be (e.g. `log.info("Hello World”)`,
`this.do_work()`, and `MyStringUtils.chop_string(...)`, etc.).
> If you look at GROOVY-12354, it now has a three way setting for the
> existing flag. […]
Thanks for that fix. Yeah, that's probably a great middle ground until
such time as the feature is fully and completely ready for prime-time
to be used everywhere. I look forward to getting increased performance
benefits from all of the hard work done to optimize and improve for
both the JVM and AOT VM’s.
Thanks for the extensive write-up for solutions/workarounds for RC-1
users! I am sure others will appreciate it too.
> [...] So your gut was right!
He he, yeah, I've learned to trust if after 15+ years doing software
engineering. It helps to be slightly naturally lazy and prefer to take
the easy route of "eh, just hit the off button. It's fine". :)
> I weighed up re-rolling against what RC-1 also carries [but decided
> against it.]
Agreed. Make sense. Given the size of the v6 releases, I would have
been surprised if it _had_ been re-rolled. Nevertheless, it was a good
opportunity to surface the issue's visibility all the same and ensure
that it didn't actually make it all the way into the real release.
> The hardening work relates to the ASF's Responsible AI Initiative
> which you can read more about[…]
Nice, that's good to see. It would be nice to read more about how
the funds get dispersed and the details of it all in more depth. I am
sure that the all of the usages of Claude Fable 5 I used for GEP-28’s
reference implementation would be good candidates for reimbursement
(slightly tongue in cheek but hey, you miss 100% of the shots you
don't take :)).
Thanks,
Matt
------ Original Message ------
>From "Paul King" <[email protected]>
To [email protected]
Date 9/7/2026 7:23:33 AM
Subject Re: [VOTE] Release Apache Groovy 6.0.0-RC-1
>
>
>Thanks again for your thoughtful response. Comments inline.
>
>
>
>On Sun, Sep 6, 2026 at 7:59 AM Matt M <[email protected]> wrote:
>>
>>
>>
>> > [...] Just saying, that there is no 100% solution, but there should
>>
>> > be one for this specific case.
>>
>>
>>
>> Yeah, fair enough. If I am understanding things correctly, it seems
>>
>> there's a bit more nuance involved in this as well, which makes sense.
>>
>> I haven't checked Groovy pre-6 just yet though to verify the results
>>
>> there; IIRC, the callstack is correct/works as expected for Groovy
>>
>> v5.X (though I could just be misremembering).
>
>
>
>Things like these:
>
>
>
> log."$level"(msg)
>
> log.invokeMethod('info', [msg] as Object[])
>
>
>
>Have the same problem in Groovy 5. They show as
>
>org.codehaus.groovy.reflection.CachedMethod.invoke instead of the real
>
>call.
>
>
>
>[SNIP]
>
>
>>
>> For the various solutions proposed, my gut instinct says changing the
>>
>> flag's default is the pragmatic answer. However, the most robust
>>
>> solution of the ones proposed seems to be the third one "change indy
>>
>> to invoke on cold path bypassing invokeReflective and use
>>
>> method/accessor directly", but I am not a ranking expert to be the
>>
>> judge of that being the reasonable solution overall. I'll defer and
>>
>> trust others' judgment on this.
>
>
>
>If you look at GROOVY-12354, it now has a three way setting for the
>
>existing flag.
>
>The true/false values set it on or off. Unset, it becomes opt-in for
>
>normal Groovy
>
>but turned on by default for AOT-linked call sites (native images). So
>
>your gut was right!
>
>We know the tier is a good option for native images and there were more cases
>
>where it also improved performance but we need to do better reporting
>
>on such cases
>
>and it makes sense for us to take more time to do that without the
>
>forced opt-in.
>
>
>
>There are some good workarounds for RC-1 users (points 2-6 closely
>
>matching what is now in the docs for folks who do want to opt-in):
>
>1. Turn the tier off. `-Dgroovy.indy.cold.reflection=false` as a JVM
>
>argument restores the 5.x behaviour, with no measurable cost. It must
>
>be a command-line property because it is read once when IndyInterface
>
>initialises. Lead with this; the rest is for people who cannot change
>
>JVM arguments, or who still see runtime frames afterwards.
>
>2. `@CompileStatic` on the classes whose log locations matter. Direct
>
>calls bypass the tier, for ordinary calls; a dynamic method name still
>
>goes through the metaclass.
>
>3. JUL: `-Djdk.logger.packages=org.codehaus.groovy,groovy.lang` at run
>
>time, or the `logp` methods with an explicit source. Also covers
>
>dynamic method names and explicit `invokeMethod`, which show runtime
>
>frames on every Groovy version.
>
>4. Logback: add `jdk.internal.reflect`, `java.lang.reflect`,
>
>`sun.reflect`, `org.codehaus.groovy.` and `groovy.lang.` to the
>
>context's framework packages programmatically before logging starts.
>
>Same coverage as item 3.
>
>5. Log4j2: nothing short of option 1 or 2.
>
>6. Stack traces: `StackTraceUtils.sanitize` strips every frame the
>
>runtime adds. The logger settings above do not change exception
>
>traces.
>
>
>
>I weighed up re-rolling against what RC-1 also carries:
>
>* roughly two dozen security hardening fixes, covering things like
>
>bounded JSON and XML parsing depth, regex cost limits, file-permission
>
>preservation in tooling, escaping in generated source, and
>
>SecureASTCustomizer coverage gaps.
>
>* MOP trampolines
>
>* metaclass race and mutation fixes
>
>* the parser cache bound behind the 5.1.1 OOM report
>
>* compiler error tolerance and machine-readable diagnostics
>
>* the concurrency channel-select API
>
>All of which need feedback from real projects that a re-roll would postpone.
>
>
>
>And we have been working on more hardening, so we might prepare RC-2
>
>even as early as later this week.
>
>The hardening work relates to the ASF's Responsible AI Initiative
>
>which you can read more about here:
>
>
>
>https://www.apache.org/foundation/initiatives/#responsible-ai-initiative
>
>
>
>
>
>Cheers, Paul.
