Re: make dist fixes

[Eric Blake]

Actually, the bug was in jikes 1.15, and is still in the jit.  JLS 13
requires that compilers emit method references relative to the class
that qualifies the method invocation, even if that class only inherits
the method.  It is then up to the VM to correctly track inheritance
issues when resolving method calls.  Sun's javac 1.3 also had this bug,
JDK 1.4 compiles the way jikes 1.15a does (ie. Encoder8859_1.loadTable).

It makes a difference in this example:

in A.java:
class A
{
  static void m() { System.out.print("a"); }
}

in B.java:
class B extends A {}

in C.java:
class C
{
  public static void main(String[] args)
  {
    B.m();
  }
}

Now, recompile B.java:
class B extends A
{
  static void m() { System.out.print("b"); }
}

The result of executing the (unchanged) C.class should now be "b", not
"a".

This is also the reason that Sun's javap program will often list null as
the method or field name for classes compiled with javac 1.4, because
they have not yet fixed javap to take inheritance into account.

Mark Wielaard wrote:
> 
> 
> The problem seems to come from the fact that jikes 1.15 (and gcj)
> generate things like:
> 1804: invokestatic #34=<Method
> gnu.java.io.encode.EncoderEightBitLookup.loadTable ()void>
> 
> But jikes 1.15a (from CVS) generates:
> 1804: invokestatic #33=<Method
> gnu.java.io.encode.Encoder8859_1.loadTable ()void>
> 
> Since loadTable() is a static method in (the superclass)
> EncoderEightBitLookup not in (the subclass) Encoder8859_1 it seems that
> jikes 1.15a generates wrong code in this case.
> 
> Cheers,
> 
> Mark

-- 
This signature intentionally left boring.

Eric Blake             address@hidden
  BYU student, free software programmer