[GROOVY-8455] @TupleConstructor gives wrong ordering when includeSuperFields is set

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 2.5.0-beta-3
• Assignee: Paul King
• Reporter: Paul King
• Created: 22/Jan/18 00:31
• Updated: 06/Mar/18 23:25
• Resolved: 23/Jan/18 01:25

Description

When the includeSuperProperties flag is set, @TupleConstructor includes those properties and historically has done it with properties from parent classes first. This is also true if just the includeSuperFields flag is set. When both flags are set the intention was to keep this ordering but currently that is not the case.

Here is an example:

import groovy.transform.*

class Foopubf{}
class Foop{}
class Foopp{}
class Foo {
  Foop foop1
  public Foopubf foopubf
  protected Short fooProtField = 42
  void setFooPseudoProp(Foopp fpp) {}
  Foopp getFooPseudoProp() { null }
}

class Barpubf{}
class Barp{}
class Barpp{}
class Bar extends Foo {
  Barp barp
  public Barpubf barpubf
  protected Integer barProtField = 150
  Barpp getBarPseudoProp() { null }
  void setBarPseudoProp(Barpp bpp) { }
}

class Bazpubf{}
class Bazp{}
class Bazpp{}
@TupleConstructor(includeFields=true, includeSuperFields=true, includeSuperProperties=true)
class Baz extends Bar {
  Bazp bazp
  public Bazpubf bazpubf
  protected Long bazProtField = 2000L
  Bazpp getBazPseudoProp() { null }
  void setBazPseudoProp(Bazpp bpp) { }
}

Baz.constructors.each {
    println it
}

which produces:

public Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf,java.lang.Integer,Bazp,Bazpubf,java.lang.Long)
public Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf,java.lang.Integer,Bazp,Bazpubf)
public Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf,java.lang.Integer,Bazp)
public Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf,java.lang.Integer)
public Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf)
public Baz(Foop,Barp,Foopubf,java.lang.Short)
public Baz(Foop,Barp,Foopubf)
public Baz(Foop,Barp)
public Baz(Foop)
public Baz()

Here, Barp is meant to be the 4th not 2nd param. This is a breaking change but I believe that includeSuperFields is rarely used and the two flags together perhaps slightly more so. Given that I am about to add JavaBean properties into the mix, it seems best to fix this now. The workaround for those requiring the old behavior is to add an includes annotation attribute and specify the required order. For the above example: includes='foop,barp,foopubf,...'.

Issue Links

• links to: GitHub Pull Request #655