I shouldn't try to respond to emails while rushing between conference
sessions. Refreshed my memory and yes, the current provisions for 2.4
compatibility don't really help. I'll see if Jochen has some ideas on how
we could improve that.

On Wed, Sep 26, 2018 at 12:01 PM Paul King <pa...@asert.com.au> wrote:

> I'll have to look a little more closely. There is some provision for
> handling backwards compatibility. The string value of the class name of
> Annotations is compared with "groovy.transform.Immutable", which will
> handle some cases but we've removed the annotation attributes like
> knownClasses so that is probably going to impact the ability of those
> annotations to be even read. We don't need those annotation attributes any
> more but I am unsure whether we can add them back in a way that won't
> impact our annotation collector usage. I'll have to research unless someone
> else knows off the top of their head.
>
> Cheers, Paul.
>
>
> On Tue, Sep 25, 2018 at 4:39 PM Cédric Champeau <cedric.champ...@gmail.com>
> wrote:
>
>> Hi folks,
>>
>> Gradle 5 is migrating to Groovy 2.5 (yay!). However, we discovered
>> several regressions (in @CompileStatic, in covariant return type checking,
>> ...) that may make the migration painful. One of them is unexpected for our
>> users: the @Immutable AST transformation changed the runtime checks, so a
>> class compiled with 2.4 running on 2.5 would suddenly fail. An example of
>> such a problem has been reported at
>> https://github.com/ajoberstar/grgit/issues/237
>>
>> Our partners at Netflix already mentioned they had to fork several
>> plugins to accommodate the problem. While the new checks are legit, the
>> fact that it's an AST xform (happening at compile time) and that the
>> additional check happens at runtime can be surprising.
>>
>> I'm not sure if we need to change this, but having an incompatibility may
>> be annoying.
>>
>

Reply via email to