> [...] 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). >From my testing of Groovy 6, using `MethodHandle` (i.e. disabling the flag) does make the callstack correct/work as expected. Well at least in so far as I am not seeing `jdk.internal.reflect.DirectMethodHandleAccessor.invoke` for everything in my logs. Interesting call out on `metaClass` though. That's something else that will need to be tested and verified to see how it shakes out. I would imagine though, since `metaClass` is a legitimate user-facing mechanism, it is not inconceivable that it should be expected and/or desired as a possible invocation site/exposed callstack frame. At the very least, it seemed like Paul was able to replicate the overall issue though, and provided some further examples and samples in the aforementioned referenced bug ticket beyond the initial use case I reported. Though, yeah, based on these notes here, there are likely a few other edge cases too that would be good to have under test. > runtime, not compiler. [...] A series of things we can do for the > overall situation would be: True, I used the word "compiler" to just mean the language’s codebase/implementation in its entirety, but yeah "runtime" is more precise. Slightly sloppy choice of words on my part. 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. > I over looked your mail it seems - cannot find it either. :( This is very sad. Unfortunately, I have now also encountered that problem just today for an earlier email reply I made to the dev-mailing list. Hopefully, the infra ticket gets resolved soon to fix the issue. Anyhow, I usually check the archive (https://lists.apache.org/[email protected]) just in case to make sure my emails at least exist there, if nothing else. Thanks, Matt ------ Original Message ------ >From "Jochen Theodorou" <[email protected]> To [email protected] Date 9/5/2026 4:33:04 PM Subject Re: [VOTE] Release Apache Groovy 6.0.0-RC-1 > > >On 9/5/26 18:24, Matt M wrote: >> >> -1 (binding) >> >> >> >> I was hoping that my earlier on the indy cold reflection issue _might_ >> >> have been caught early enough to get the issue addressed before the >> >> next release window; however, given that we are escalating from Groovy >> >> 6 being in beta to a first release candidate, I feel that I should >> >> call this out as a blocking issue and be a voice of dissent. > > > >I over looked your mail it seems - cannot find it either. > > >> >> TL;DR: Given this is an RC, the issue surfaced with >> >> `groovy.indy.cold.reflection` being enabled/on by default and how it >> >> affects the callstack >> >> (https://issues.apache.org/jira/browse/GROOVY-12354) [...] > > > >The only variant where something like that is potentially hidden in > >Groovy is when the call is done via invokedynamic or via direct call. > >If the invocation happens through the meta class for example it cannot > >be hidden. > > > >If callsite caching is used (pre Groovy 6) then there is potentially a > >runtime generated accessor method on the stack, that may show up in the > >trace. And right now, with the cold path from Daniel`s latest change, a > >accessor method may show up again. Then there are cases of proxying that > >could cause that, maybe MethodHandle as well. > > > >Just saying, that there is no 100% solution, but there should be one for > >this specific case. > > > >[...] >> >> From an end user perspective, the new default for how Groovy handles >> >> dynamic invocations is a very obscure compiler implementation detail, > > > >runtime, not compiler. And invokedynamic not adding stuff on the > >callstack is actually the new part compared to older versions. But yes, > >that is a regression. I agree. > > > >A series of things we can do for the overall situation would be: > > > >* change the flag to not do the cold reflection path anymore by default. > >But then, when would we ever turn that on then? It was supposed to be an > >experimental version to be turned on for the final release. > >* add @Hidden to the accessor Daniel added (generated bytecode only) > >* change indy to invoke on cold path bypassing invokeReflective and use > >method/accessor directly. > > > >bye Jochen > >
