James Daugherty created GROOVY-12554:
----------------------------------------

             Summary: 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


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)

Reply via email to