Community
Participate
Working Groups
The Eclipse compiler generates classes that throw a java.lang.VerifyError when they are loaded. If Sun's javac or IBM's jikes is used to compile the same class, no error occurs. This happens when an inner class accesses a protected field belonging to the base class of the outer class if the base class and the outer class are in different packages. (Hope that makes sense!) java.lang.VerifyError: (class: oranges/Derived$Inner, method: bug signature: () V) Incompatible type for getting or setting field at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:140) at Main.main(Main.java:4) Exception in thread "main"
Created attachment 4277 [details] Bug demonstration classes The VerifyError.jar file contains a simple Eclipse project to demonstrate the bug. I contains classes that I've compiled using 2.1 rc3a - you may run it by typing "java -jar VerifyError.jar". Tested with java 1.4.1_01 and 1.4.1_02
The bug is in the innerclass emulation. In reference from Derived$Inner.bug() to 'c.foo', we generate code as if 'c' was defined in enclosing type Derived (where it is defined at depth 0). Method void bug() 0 getstatic #29 <Field java.io.PrintStream out> 3 aload_0 4 getfield #16 <Field oranges.Derived this$0> // SHOULD NOT BE HERE 7 getfield #18 <Field oranges.Derived c> 10 invokestatic #35 <Method java.lang.String access$0(oranges.Derived)> 13 invokevirtual #41 <Method void println(java.lang.String)> 16 return }
As a workaround, you may simply write 'this.c.foo' instead of 'c.foo'.
Problem isolated. #setDepth implementation weren't doing anything when depth is set to zero (can occur for QualifiedNameReferences when binding subsequent fields). Fix is quite simple.
Created attachment 4279 [details] setDepth patch
Tushar - isn't the workaround a viable solution for 2.1 ?
Yes, the workaround is good :-) Thanks for the quick turnaround Philippe :-)
+1
Fix released for integration
Verified.
