CompilerConfiguration: clarify indy is always on

[dilyanpalauzov]

Consider applying also this patch. I think it is useful in eliminating no-indy cases, but I am not going to validate myself this assumption.

I think when searching with

grep -ri indy
grep -ri invokedynamic

all occurences should be evaluated, whether they can be deleted.

This probably is also irrelevant now from subprojects/performance/README.adoc:

In order to run the benchmarks against InvokeDynamic generated classes use
the `indy` property:

    ./gradlew -Pindy=true :perf:jmh

[eric-milles]

"always enabled" should probably read "enabled by default" -- it is still possible to disable until all the call site code is removed (see #1934)

[dilyanpalauzov]

At https://groovy-lang.org/releasenotes/groovy-4.0.html#Groovy4.0-indy-only is written:

For many versions, Groovy could generate classic call-site based bytecode or bytecode targeting the JDK7+ invoke dynamic ("indy") bytecode instructions. You could switch between them with a compiler switch and we had two sets of jars ("normal" and "-indy") built with and without the switch enabled. In Groovy 4.0, only bytecode using the latter approach can be generated.

For me this means that classic-site based bytecode cannot be generated and thus indy-generation is always enabled.

(from the above hyperlink)

Currently, the Groovy runtime still contains any necessary support for classes compiled using older versions of Groovy.

Is #1934 about removing support for interpreting files, compiled using Groovy 3 and utilizing call-site based bytecode?

[eric-milles]

You can still set system property "groovy.target.indy" to false or you can set optimization option "indy" to false. This will enable the old call site code generation. These default to true in Groovy 4+ and no separate artifacts are created or tested.

[dilyanpalauzov]

Is my reading of https://groovy-lang.org/releasenotes/groovy-4.0.html#Groovy4.0-indy-only correct, that (there is written) with Groovy 4.0 only indy-code can be generated, and call-site based code cannot be generated?

If my reading of that text is correct, is the text at the hyperlink also correct?