Bug 35456

Summary: The Eclipse compiler generates classes that throw a VerifyError
Product: [Eclipse Project] JDT Reporter: Tushar Pokle <tushar.pokle>
Component: CoreAssignee: Philipe Mulet <philippe_mulet>
Status: VERIFIED FIXED QA Contact:
Severity: critical    
Priority: P3    
Version: 2.1   
Target Milestone: 2.1 RC4   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Bug demonstration classes
none
setDepth patch none

Description Tushar Pokle CLA 2003-03-21 07:46:34 EST 
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"
Comment 1 Tushar Pokle CLA 2003-03-21 07:54:36 EST 
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
Comment 2 Philipe Mulet CLA 2003-03-21 08:33:21 EST 
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
}
Comment 3 Philipe Mulet CLA 2003-03-21 08:34:21 EST 
As a workaround, you may simply write 'this.c.foo' instead of 'c.foo'.
Comment 4 Philipe Mulet CLA 2003-03-21 08:50:02 EST 
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.
Comment 5 Philipe Mulet CLA 2003-03-21 08:52:03 EST 
Created attachment 4279 [details]
setDepth patch
Comment 6 Philipe Mulet CLA 2003-03-21 09:25:52 EST 
Tushar - isn't the workaround a viable solution for 2.1 ?
Comment 7 Tushar Pokle CLA 2003-03-21 09:44:58 EST 
Yes, the workaround is good :-) Thanks for the quick turnaround Philippe :-)
Comment 8 Erich Gamma CLA 2003-03-21 10:37:30 EST 
+1
Comment 9 Kai-Uwe Maetzel CLA 2003-03-24 12:31:38 EST 
+1
Comment 10 Dirk Baeumer CLA 2003-03-24 13:03:07 EST 
+1
Comment 11 Darin Wright CLA 2003-03-24 13:30:12 EST 
+1
Comment 12 Philipe Mulet CLA 2003-03-25 12:00:32 EST 
Fix released for integration
Comment 13 David Audel CLA 2003-03-28 06:45:28 EST 
Verified.