groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul King (JIRA)" <>
Subject [jira] [Commented] (GROOVY-8107) Binary incompatibility problems between compiled code in Groovy 2.4.7 vs 2.4.9
Date Sun, 05 Mar 2017 22:09:32 GMT


Paul King commented on GROOVY-8107:

Jochen, the binary incompatibility isn't in any Groovy class itself but the generated trait
helper classes were backward compatible only not forward compatible.

The attached PR keeps both the old and new fields in the generated trait class and changes
the priority to look for the new ones first. I'd propose merging this and releasing 2.4.10.
It should then allow traits compiled under 2.4.10 to be used from 2.4.7 which is what is failing
now. Honoring of the final field wouldn't work in that case but the behavior would be equivalent
to 2.4.7 behavior.

I built a local 6.1.0.BUILD-SNAPSHOT of grails-data-mapping and the groovy-npe-test example
now compiles.

> Binary incompatibility problems between compiled code in Groovy 2.4.7 vs 2.4.9
> ------------------------------------------------------------------------------
>                 Key: GROOVY-8107
>                 URL:
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 2.4.9
>            Reporter: Graeme Rocher
>         Attachments:,
> There are currently various binary incompatibility problems that are presenting a challenge
for us moving forward with upgrading to Groovy 2.4.9 in Grails.
> One of them is Groovy traits compiled with Groovy 2.4.9 are not usable in Groovy 2.4.7
due to the following exception:
> {code}
> Error:Groovyc: While compiling tests of grails-datastore-gorm-hibernate5_test: BUG! exception
in phase 'semantic analysis' in source unit '/Users/graemerocher/grails/gorm-hibernate5/grails-datastore-gorm-hibernate5/src/test/groovy/grails/gorm/tests/jpa/SimpleJpaEntitySpec.groovy'
> 	at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(
> 	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(
> 	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(
> 	at org.codehaus.groovy.control.CompilationUnit.compile(
> ...
> Caused by: java.lang.NullPointerException
> 	at org.codehaus.groovy.ast.expr.VariableExpression.<init>(
> 	at org.codehaus.groovy.transform.trait.TraitComposer.applyTrait(
> 	at org.codehaus.groovy.transform.trait.TraitComposer.doExtendTraits(
> 	at org.grails.compiler.gorm.GormEntityTransformation.visit(GormEntityTransformation.groovy:338)
> 	at org.grails.compiler.gorm.JpaGormEntityTransformation.visit(JpaGormEntityTransformation.groovy:50)
> 	at org.grails.compiler.gorm.GlobalJpaEntityTransform.visitClass(GlobalJpaEntityTransform.groovy:43)
> 	at org.grails.compiler.gorm.GlobalJpaEntityTransform.visit(GlobalJpaEntityTransform.groovy:35)
> 	at org.codehaus.groovy.transform.ASTTransformationVisitor$
> 	at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(
> 	... 22 more
> {code}
> This is an issue and IMO there should never be binary incompatible breaking changes between
different patch releases of Groovy 2.4.x.
> The other issue is
> Which is marked as fixed, but currently code already compiled in Groovy 2.4.7 is throwing
a NPE using 2.4.9 such as:
> {code}
> Caused by: java.lang.NullPointerException: null
>         at org.codehaus.groovy.runtime.DefaultGroovyMethods.leftShift(
>         at grails.artefact.Interceptor$Trait$Helper.matchAll(Interceptor.groovy:109)
> {code}
> We can't really ask people to start recompiling existing published libraries for a patch
release of Groovy so are looking for a path forward with these problems.
> It is my opinion that we should be aim to never break binary compatibility in a major
release let alone in a patch release.

This message was sent by Atlassian JIRA

View raw message