CFR does not reorder super call if mis-placed

[PhoenixVX]

CFR version

CFR version 0.152 and latest commit as of #c69ed17 was tested.

Compiler

For the class file, I have not found a decent way to reproduce this bytecode ordering. Accordingly, Sun Microsystems Java 1.6.0_17 was used to compile the original file, but was set to target Java 1.5 according to the META-INF and version of the individual class files.

Description

In practice, a super call must always be at the top of the constructor in source code, but in bytecode, this can be slightly ignored. CFR accordingly, misplaces the super call to where it is in bytecode, in the source code, thus the piece of code simply refuses to compile since the super call is mis-placed.

Example

This is the censored version of the bytecode, which in turns produce the next few lines of code.

  MyCustomThread(MyCustomClass, java.lang.String);
    flags: 
    Code:
      stack=2, locals=3, args_size=3
         0: aload_0       
         1: aload_1       
         2: putfield      #11;                // Field myClass:LMyCustomClass;
         5: aload_0       
         6: aload_2       
         7: invokespecial #14;                // Method java/lang/Thread."<init>":(Ljava/lang/String;)V
        10: aload_0       
        11: iconst_1      
        12: invokevirtual #18;                // Method setDaemon:(Z)V
        15: aload_0       
        16: invokevirtual #22;                // Method start:()V
        19: return   

    MyCustomThread(MyClass myClass, String string) {
        this.myClass = myClass;
        super(string);
        this.setDaemon(true);
        this.start();
    }

Simply reordering the super call to the top of method fixes the actual behavior.