Dark Mode

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

CompilerConfiguration: clarify indy is always on#2319

Open
dilyanpalauzov wants to merge 1 commit intoapache:masterfrom
dilyanpalauzov:noindy_since4
Open

CompilerConfiguration: clarify indy is always on#2319
dilyanpalauzov wants to merge 1 commit intoapache:masterfrom
dilyanpalauzov:noindy_since4

Conversation

Copy link

dilyanpalauzov commented Oct 14, 2025

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

Copy link
Member

eric-milles commented Oct 21, 2025

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

Copy link
Author

dilyanpalauzov commented Oct 21, 2025

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?

Copy link
Member

eric-milles commented Oct 21, 2025

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.

Copy link
Author

dilyanpalauzov commented Oct 22, 2025

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants