[
https://issues.apache.org/jira/browse/GROOVY-8107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15896572#comment-15896572
]
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: https://issues.apache.org/jira/browse/GROOVY-8107
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 2.4.9
> Reporter: Graeme Rocher
> Attachments: groovy-npe-test.zip, interceptor-issue.zip
>
>
> 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'
> null
> at
> org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:932)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:590)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:566)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:543)
> ...
> Caused by: java.lang.NullPointerException
> at
> org.codehaus.groovy.ast.expr.VariableExpression.<init>(VariableExpression.java:64)
> at
> org.codehaus.groovy.transform.trait.TraitComposer.applyTrait(TraitComposer.java:247)
> at
> org.codehaus.groovy.transform.trait.TraitComposer.doExtendTraits(TraitComposer.java:111)
> 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$3.call(ASTTransformationVisitor.java:319)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:928)
> ... 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 https://issues.apache.org/jira/browse/GROOVY-8048
> 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(DefaultGroovyMethods.java:12204)
> 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
(v6.3.15#6346)
