Workaround for javac compilation order bug in maven

廉价感情. 提交于 2019-11-27 02:36:52

问题


I'm encountering a bug in the Java compiler where the order of files submitted for compilation can cause code not to compile. I've drilled down the code to isolate the smallest amount of code I could to reproduce the problem, resulting in three source files (1 class each).

public interface ActionSpec {
    public abstract int run(String param);
}


public enum Actions implements ActionSpec {
    SKIP {
        public int run(String d) {
            return 0;
        }
    };
}

public class Program {

    public static void main(String[] args) {
        Actions.SKIP.run("hello");
    }
}

The problem is reproducible by having javac arguments in a particular order. In short, in order to succeed, the Actions class must always be compiled before the Program class which uses it, otherwise javac just fails to deal with it in a sane way:

# this case fails
echo "Trying order: javac Program.java Actions.java ActionSpec.java"
rm *class
javac -verbose Program.java Actions.java ActionSpec.java

# this case fails
#rm *class
#javac Program.java Actions.java ActionSpec.java

# this case fails
#rm *class
#javac ActionSpec.java Program.java Actions.java

# this case succeeds
#rm *class
#javac ActionSpec.java Actions.java Program.java

# this case succeeds
#rm *class
#javac Actions.java ActionSpec.java Program.java

# this case succeeds
#rm *class
#javac Actions.java Program.java ActionSpec.java

The compilation error, when it occurs, is always the same - the run method on the Actions enum instances cannot be found, even though they all implement an interface that has that run method.

Program.java:6: cannot find symbol
symbol  : method run(java.lang.String)
location: class problem.Actions
        Actions.SKIP.run("hello");

The bug seems related to this one reported on Oracle's site. I'm using javac 1.6.0_29, on mac os x 10.7.2 x86_64, but have also reproduced it on Linux.

This problem became apparent as I am using Maven to build, and don't appear to have any control over the order of compilation. So I am looking for a workaround to either force maven to compile files in such an order as to avoid this compiler bug, or fiddle with the compiler flags (or something like it) to avoid it. The problem crops up on workstations and in continuous integration environments alike, so it would have to work across the board. Any suggestions?

EDIT: Just tried the following workaround, which despite merely assigning the enum in question to a variable with the type of the interface it implements, surprisingly causes the error to disappear.

public class Program {

    public static void main(String[] args) {
        ActionSpec a = Actions.SKIP;
        a.run("hello");
    }
}

Still interested in others opinions.


回答1:


I played around, and found that adding simple cast:

public static void main(String[] args) {
    ((ActionSpec)Actions.SKIP).run("hello");
}

solves this problem. Passing this enum as method parameter as interface would also do the trick




回答2:


It's the bug reported in http://bugs.sun.com/view_bug.do?bug_id=6724345

The workaround suggested should work if you are still using Java 6 compiler. The bug is fixed in Java 7.




回答3:


Here's how I would do it:

  • Move the ActionSpec interface to another Maven project. We usually have interfaces and common domain classes in their own project, e.g. foo-service-specs.
  • Keep the other classes in the implementation project, e.g. foo-service-impl.
  • Include the foo-service-specs project as a dependency in foo-service-impl.

By doing this, you can make sure that the compilation order is working, and it should also work for continuous integration.




回答4:


Try multiple executions of the compiler plugin. Using default-compile as the first execution ID adds the new config to Maven's default compiler execution. Use the <includes/> config elements in the default execution to compile the enums first. For the second execution you'd use a combination of <includes> and <excludes> , where <includes> would be all of your code and excludes would be the enums already compiled.

I think this will work for your example program but I did not test it. I have tested something similar before with Maven 3 and it worked fine.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.3.2</version>
    <configuration>
        <source>1.6</source>
        <target>1.6</target>
    </configuration>
    <executions>
        <execution>
           <id>default-compile</id>
           <goals><goal>compile</goal></goals>
           <configuration>
              <includes>
                  <include>**/Actions.*</include>
              </includes>
           </configuration>
        </execution>
        <execution>
           <id>second</id>
           <goals><goal>compile</goal></goals>
           <configuration>
              <includes>
                  <include>**/*</include>
              </includes>
              <excludes>
                  <exclude>**/Actions.*</exclude>
              </excludes>
           </configuration>
        </execution>
    </executions>
</plugin>



回答5:


We had the same problem. Multiple executions of the maven compiler plugin worked for us...



来源:https://stackoverflow.com/questions/9505857/workaround-for-javac-compilation-order-bug-in-maven

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!