[
https://issues.apache.org/jira/browse/GROOVY-12554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18134461#comment-18134461
]
ASF GitHub Bot commented on GROOVY-12554:
-----------------------------------------
testlens-app[bot] commented on PR #3083:
URL: https://github.com/apache/groovy/pull/3083#issuecomment-6508241851
## ✅ All tests passed ✅
🏷️ Commit: cc133ca899f92da6a36252e650ee601ce19bf6bb
▶️ Tests: 122876 executed
⚪️ Checks: 26/26 completed
---
_Learn more about TestLens at
[testlens.app/docs](https://testlens.app/docs/features/pr-comment/)._
> The order of super$ MOP methods depends on whether the superclass's
> interfaces were built by reflection or read from bytecode
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12554
> URL: https://issues.apache.org/jira/browse/GROOVY-12554
> Project: Groovy
> Issue Type: Bug
> Components: class generator
> Affects Versions: 4.0.33, 5.1.3
> Reporter: James Daugherty
> Priority: Major
>
> For every superclass method that a class calls through {{super}} in dynamic
> Groovy, the class gets a synthetic {{super$N$name}} method. Groovy writes
> these in the order in which it finds the methods, and that order follows the
> class nodes of the superclass's interfaces. When a transformation adds an
> interface with a class node built by reflection, as GORM does for the traits
> of domain classes, the order comes from {{Class.getDeclaredMethods()}}, which
> is unspecified. When the superclass is read from bytecode, it comes from the
> class file. So the same source compiles to a different class file depending
> on what else is compiled, and in principle on the JVM.
> {noformat}
> super$ methods of Sub, compiled together with Base: alpha beta
> delta gamma kappa mid omega zeta
> super$ methods of Sub, compiled against Base already compiled: zeta alpha mid
> omega beta kappa delta gamma
> {noformat}
> Reproduced with 4.0.33, 5.1.3 and master. A reproducer with a small
> transformation that adds an interface with {{ClassHelper.make(Class)}}, a
> groovyc script and an incremental Gradle build:
> https://github.com/jdaugherty/groovy-mop-method-order
> *Cause*
> {{MopWriter.visitMopMethodList}} generates the MOP methods in the order of
> {{getDeclaredMethodsMap()}} of the superclass, which adds the methods of the
> superclass's interfaces in the order their class nodes list them: by
> reflection for a node made with {{ClassHelper.make(Class)}}, from the class
> file for a node read from bytecode.
> *Proposed fix*
> Sort the MOP methods by name and type descriptor before generating them. The
> order of methods in a class file does not matter at run time, and
> {{MetaClassImpl}} sorts the MOP methods it finds itself.
> Found while making incremental builds of a Grails application produce the
> same classes as a full build; see also GROOVY-12550 and GROOVY-12544.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
