Does indy by default mean

1.  only generate one set of groovy-* artifacts where any .groovy source files in the Groovy source itself are compiled using indy (no more separate indy jars)


2.  continue to have two sets of artifacts where the indy set would go in lib/ by default and -noindy jars would exist that could replace them if old callsite code is desired

I took Russel's original suggestion to mean #1 and I would be in favor of that for 3.0. I think any performance concern would largely be confined to some of the sub-projects in the Groovy codebase since most of core is written in Java.

The other consideration in making indy default is whether indy will be enabled by default for compiling user supplied source and this is what I think most are referring to in the replies.  This is where I agree that there is no rush to remove the callsite code and it would be good to have a --no-indy option for the next several major versions after that change is made.


On Tue, May 30, 2017 at 4:29 PM, Jochen Theodorou <> wrote:
in my opinion if JDK8 is the minimum requirement we can switch to indy as default, while keeping the old call site caching as is.

It is more that in the long term we want to get rid of code that has no future and all that. But I see no hard requirement to do those things just because of indy beig the default

bye Jochen

On 30.05.2017 23:48, Mario Garcia wrote:
If I didn't get it wrong, there is a possibility to have indy as a
default only if:

 1. Callsite caching is rewritten to work with indy/no indy
 2. We keep binary compatibility Groovy 3 / JDK7 until Gradle moves to
    Groovy 3
 3. Then we will be able to move to Groovy with JDK8 and set Indy by default

Is that correct ?

2017-05-30 17:24 GMT+02:00 Daniel Sun <

    > I don't think it would be good if gradle stayed on Groovy 2.x. That would
    counter the acceptance of Groovy 3



    View this message in context:
    Sent from the Groovy Dev mailing list archive at