I created an issue to track: https://issues.apache.org/jira/browse/GROOVY-12354
On Sat, Sep 5, 2026 at 6:00 AM Paul King <[email protected]> wrote: > > Hi Matt, > > Thanks for looking into this and sorry for the delay in getting back > to you. The PR description was stale when it mentioned the defaults > but you are right that the logging behavior (and potentially other > scenarios) are impacted. I should have looked deeper into that > earlier. I'll ensure this is in the release notes and we might tweak > the settings before the next release. > > I'll investigate further, and if it looks serious enough, we can > re-roll the RC-1 candidate out for voting. Or we leave it go out to > gain further feedback (with the release note to warn impacted users) > and do another release soon. I am sure we'll have other things to fix > too. > > Cheers, Paul. > > On Fri, Sep 4, 2026 at 8:32 AM Matt M <[email protected]> wrote: > > > > Hey folks, > > > > I just wanted to follow-up on this. I am curious if this is something > > others > > are seeing too. > > > > Thanks, > > Matt > > > > > > ------ Original Message ------ > > From "Matt M" <[email protected]> > > To "[email protected]" <[email protected]> > > Date 8/29/2026 1:41:09 PM > > Subject [Groovy 6] GROOVY-12137: - Indy Cold Reflection Snag/Defaults > > Inconsistency > > > > > > > > > > >Hey folks, > > > > > > > > > > > >I wanted to send this over the mailing list as I am not sure it's a > > > > > >"bug" per-se and there might be some discussion on it too. Hopefully > > > > > >this is helpful all the same. > > > > > > > > > > > >I have been using Groovy 6's recent betas and believe I have found a > > > > > >snag with the new experimental invoke dynamic cold reflective > > > > > >feature/functionality. There's two "threads" for discussion here that > > > > > >are of note. I have split them out explicitly for the sake of > > > > > >convenience and clarity. > > > > > > > > > > > >— > > > > > > > > > > > >First: `groovy.indy.cold.reflection` Default Value Mismatch? > > > > > > > > > > > >It looks like the default value of `groovy.indy.cold.reflection` is > > > > > >set to true/on by default in the code at > > > > > >https://github.com/apache/groovy/blame/master/src/main/java/org/codehaus/groovy/vmplugin/v8/IndyInterface.java#L64. > > > > > >However, according to the Git commit message/PR description that > > > > > >merged in the feature and that line > > > > > >(https://github.com/apache/groovy/pull/2673), it is supposed to _off_ > > > > > >by default. There's probably good arguments for both. > > > > > > > > > > > >My best guess is that the PR description/Git commit message is > > > > > >erroneous here and it really _is_ supposed to be enabled and on by > > > > > >default. However, I could very well likely be wrong and mistaken, I am > > > > > >just speculating. > > > > > > > > > > > >The slight mismatch not withstanding, I was a bit surprised to find > > > > > >this out anyway since the facility is listed as an experimental > > > > > >feature in the ticket GROOVY-12137 and throughout the code’s > > > > > >documentation (granted, it's listed as "incubating" in the release > > > > > >notes as part of AOT support). I would think that experimental > > > > > >features are generally are opt-in (i.e. I interpret experimental as > > > > > >not stable/reliable for production usage just yet). Not wrong and I am > > > > > >sure that the rationale behind it makes sense (i.e. if we don't turn > > > > > >it on then nobody would know to use it), just surprising that's all. > > > > > > > > > > > >BTW, regardless of how it's resolved, the feature flag is quite well > > > > > >hidden anyways. By sheer dumb luck, I only knew about this facility > > > > > >even being feature flagged since it was part of some other performance > > > > > >work I was doing on the compiler and just so happened to be of > > > > > >relevance that I had it in the back of my mind. It's not listed as > > > > > >having a toggle'able flag anywhere in the release notes on/at > > > > > >https://groovy-lang.org/releasenotes/groovy-6.0.html either. I would > > > > > >then guess that the feature flag is more of a convenience escape-hatch > > > > > >for rare edge cases as part getting the feature ready to be > > > > > >finalized/made production-ready, rather than an explicitly, fully > > > > > >supported switch intended for end-user configuration at their > > > > > >discretion? > > > > > > > > > > > >— > > > > > > > > > > > >Second: Cold Reflection & Callstack Snag. > > > > > > > > > > > >This is the actual root of the "problem" and where it gets interesting > > > > > >from a design perspective. Well, I am not sure it's _exactly_ a > > > > > >"problem" per-se. It _might_ be? So in truth, I only actually noticed > > > > > >something was wrong due to seeing my logs for my application all of a > > > > > >sudden start reporting JDK internal methods as the logger's callsite > > > > > >when using Groovy 6 (e.g. all of my logs were printing > > > > > >`jdk.internal.reflect.DirectMethodHandleAccessor.invoke` as the method > > > > > >where `log.info`/etc. was being invoked from instead of their real > > > > > >method). This was extremely suspicious and didn't make sense as to why > > > > > >logging all of a sudden just kind of broke. > > > > > > > > > > > >After some investigating, I found out why I was seeing > > > > > >`jdk.internal.reflect.DirectMethodHandleAccessor.invoke` as the > > > > > >callsite: the changes in IndyDispatch to support Cold Reflective > > > > > >Invocation. Thankfully Logback had a facility already baked in, > > > > > >`%caller{N}`, for dumping out the callstack's stack trace for a number > > > > > >of frames to make finding this out much easier. > > > > > > > > > > > >Without just papering over the issue by registering Groovy's internal > > > > > >compiler packages as framework internals in Logback, I thought about > > > > > >this a bit more: I wondered if this change might subtly affect other > > > > > >things that don't expect the callstack to change/have intermediaries > > > > > >when invoked dynamically? I haven't done a thorough investigation or > > > > > >spent time digging into this in any great depth, however, I would > > > > > >imagine that there are some deeper, subtler implications elsewhere > > > > > >that this might cause. > > > > > > > > > > > >I just happened to find this out via logging, which is not necessarily > > > > > >mission critical (though one could make the argument that having data > > > > > >silently go missing from logs is far from acceptable). I would be > > > > > >curious to see if anyone else runs into subtleties with having > > > > > >reflection based invocations enabled by default. > > > > > > > > > > > >I am not saying it's a bad feature or should be removed/changed or > > > > > >anything. Just food-for-thought. > > > > > > > > > > > >— > > > > > > > > > > > >Anyhow, I just thought I should surface this to the team and in case > > > > > >anyone else runs into this issue, they can understand "what" and “why” > > > > > >a little easier. Maybe this should get some eyeballs on it before > > > > > >Groovy 6 ships so that if it needs some tweaking or extra > > > > > >documentation, it can be ready in time? > > > > > > > > > > > >Thanks, > > > > > >Matt > >
