Description David Liu 2007-04-23 19:18:26 EDT

When the following class is compiled using Eclipse's compiler, an invalid stackmap is generated.

public class TestClass {
    public TestClass(int i) {
        TestClass [] array = new TestClass[] { i == 0 ? null : null };
    }
}

Eclipse's Java compiler generates the following stackmap (displayed from javap):

  StackMapTable: number_of_entries = 2
   frame_type = 255 /* full_frame */
     offset_delta = 18
     locals = [ class TestClass, int ]
     stack = [ class TestClass, class TestClass, int ]
   frame_type = 255 /* full_frame */
     offset_delta = 0
     locals = [ class TestClass, int ]
     stack = [ class TestClass, class TestClass, int, null ]

Whereas Sun's Java compiler produces the following:

  StackMapTable: number_of_entries = 2
   frame_type = 255 /* full_frame */
     offset_delta = 18
     locals = [ class TestClass, int ]
     stack = [ class "[LTestClass;", class "[LTestClass;", int ]
   frame_type = 255 /* full_frame */
     offset_delta = 0
     locals = [ class TestClass, int ]
     stack = [ class "[LTestClass;", class "[LTestClass;", int, null ]

Specifically, Eclipse's Java compiler specifies that the Java stack contains two references to TestClass (pushed by the "anewarray" bytecode), whereas the correct Java stack actually contains two references to arrays of TestClass. However, since the verifier defaults to type inference when type checking fails, no error messages are displayed by default for the incorrect stack maps. 

[maxwell]dl156546:Test> java -classpath bin TestClass
Exception in thread "main" java.lang.NoSuchMethodError: main

When type interference is disabled, the class fails to verify:

[maxwell]dl156546:Test> java -XX:-FailOverToOldVerifier -classpath bin TestClass
Exception in thread "main" java.lang.VerifyError: Inconsistent stackmap frames at branch target 18 in method TestClass.<init>(I)V at offset 11