Up until now the compiler has been generating incorrect byte code for calling a java.lang.Object method on an interface. Specifically, the generated code reference Object.method() instead of interface.method(). When we tried to fix that recently (4285499) we immediately ran into VM failures.

You won't be able to use the compiler to produce these correct class files, as all the existing compilers have hacks to work around this VM problem. I have produced the class file for you to test against.

The class file is attached to this bug report, but shown below:


frog$ cat -n T.java
     1 public class T
     2 {
     3 public static interface I {}
     4
     5 public static class C implements I {}
     6
     7 public static void main(String[] args) {
     8 I i = new C();
     9 i.getClass();
    10 }
    11 }
frog$ jdis T.class
super public class T
{


public Method "<init>":"()V"
stack 1 locals 1
{
aload_0;
invokespecial Method java/lang/Object."<init>":"()V";
return;
}

public static Method main:"([Ljava/lang/String;)V"
stack 2 locals 2
{
new class T$C;
dup;
invokespecial Method T$C."<init>":"()V";
astore_1;
aload_1;
invokeinterface InterfaceMethod T$I.getClass:"()Ljava/lang/Class;", 1;
pop;
return;
}

public static InnerClass C=class T$C of class T;
public static abstract interface InnerClass I=class T$I of class T;

} // end Class T
frog$ newjava T
+ /net/frog/gafter/gjc-neal/build/solaris-sparc/bin/java T
#
# HotSpot Virtual Machine Error, Unexpected Signal 11
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Error ID: 4F533F534F4C415249530E43505007FF 01
#
# Problematic Thread: prio=5 tid=0x28290 nid=0x1 runnable
#
Abort
frog$ newjava -version
+ /net/frog/gafter/gjc-neal/build/solaris-sparc/bin/java -version
java version "1.4.0internal"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0internal--001215-12:08)
Java HotSpot(TM) Client VM (build 1.4beta-B45, mixed mode)
frog$