Looming Groovy 5 INDY-only Performance Problem

Hi .+,

I just saw this 2 week old comment on Grails 7/Groovy 4 INDY performance 
(bold by me; 
https://github.com/apache/grails-core/issues/15293#issuecomment-3676632134):

> Thanks for raising this issue, we also hit the problem of a massive 
> performance hit using Grails 7/Groovy 4 on our large codebase, and 
> were partially rectifying that by converting more of our code to 
> either @CompileStatic or just to Java. *Every Groovy upgrade has given 
> us challenges with compile performance, runtime performance, language 
> behaviour changes* etc *so our long term goal is to switch to pure 
> Java* which I believe will be more stable and perform better. The tip 
> of disabling indy has been very helpful because it's allowed us to get 
> over the issue for now and in fact due to the rework we've done, our 
> app is faster than before!

Even though in our large codebase we were able to successfully steer 
around this issue by going partially @CompileStatic, I feel like Groovy 
5 being INDY-only could pose more of a risk for the future of the Groovy 
language than previous changes, if more companies/orgs with larger 
Groovy applications/frameworks decide to switch to Java.

=>

 1. *To fix the root cause of performance drop-off:* /Could a Grails
    application be used to try out the INDY performance improvements
    Jochen suggested in August/ ?
     1. (As I said before, our code needs to be closed source and we
        therefore alas cannot supply the needed test case.)
 2. *To make switching to new Groovy major versions faster/easier
    under @CompileStatic/@TypeChecked:* One of the main sources of
    problems when doing the switch to a new major Groovy version we
    encounter, is that Groovy continues to be /ever more strict with
    regards to generics arguments/.
     1. A non-negligible part of the work to get the two base modules of
        our framework to compile under @CompileStatic was adding "as
        List<SomeClass>" or similar to our code, to get Groovy to accept it.
     2. I know covariance in general is a complicated & intricate
        problem, but can we instead find a Groovy solution here
        following "make the frequent case simple/fast, make the rare
        case correct", and instead of being more strict/, do things like
        e.g. a List<ChildOfGoo> being accepted as a List<Goo>/ ?
         1. Some cases can of course be solved by using List<T extends
            Goo>, but alas even this does not always work in more
            complex generics constructs.
             1. (In some cases it would help to keep the code
                Groovy-compact, if Groovy had its own more compact
                syntax for the List<? extends Goo> variety, e.g.
                List<Goo*> (i.e. appending a "*" after the type) ...)


A Groovy Happy New Year to everyone, Cheers,
mg