I created this issue to track that work: https://issues.apache.org/jira/browse/GROOVY-11158
There are possibly still a few places where we use some classes directly still. Also, we want to retain backwards compatibility, e.g. libraries/plugins compiled on earlier versions should still work in Groovy 5. The exact meaning of "older versions" is open for debate I guess but I am imagining 3.x and 4.x at least and there are certain caveats around what "still working" would mean - we have a known breaking change wrt accessing super classes. I expect there would be some classes we keep for that purpose even if we deprecate and make sure we aren't still using them directly. On Thu, Aug 17, 2023 at 12:03 AM Jochen Theodorou <blackd...@gmx.org> wrote: > Hi, > > We have those dgm helper methods we generate at build time. They are > originally used as part of the callsite caching to have less reflection > for the invocation. Accordingly they are meta methods with an invoke > method. But we are now using invokedynamic and for this we actually > would need a MethodHandle instead. > > There is also dgminfo to consider, which is basically a serialized map > version of our default groovy methods using DGM. I would keep that of > course, but I think the old GeneratedMethod is maybe not the right thing. > > Do we want to do something in that area for Groovy 5? > > bye Jochen >
