20

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.

Ben Hardy
  • 1,739
  • 14
  • 16
  • It is not surprising that with the introduction of `ActionSpec` it starts working. Maybe the bug is limited to enum and what it implements. An `import` might help too. – Joop Eggen Feb 29 '12 at 21:03
  • Have you tried adding a `public abstract int run(String d);` method to the enum? – JB Nizet Feb 29 '12 at 21:25
  • Shouldn't need to since the enum class implements the interface, and all the instances of it contain implementations of the method (or else the enum wouldn't compile). – Ben Hardy Feb 29 '12 at 23:06
  • It works for me on OpenJDK 1.6.0_23 on Ubuntu. – Paŭlo Ebermann Mar 03 '12 at 17:52

5 Answers5

5

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

Konstantin Pribluda
  • 12,329
  • 1
  • 30
  • 35
4

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.

Ken Yiu
  • 41
  • 2
0

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

Ivan Ferić
  • 4,725
  • 11
  • 37
  • 47
Christian
  • 1
0

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.

nwinkler
  • 52,665
  • 21
  • 154
  • 168
0

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>
user944849
  • 14,524
  • 2
  • 61
  • 83