Re: Patch: this$<n> initialization -vs- verification

[Eric Blake <ebb9 at email dot byu dot edu>]

Actually, this is legal according to the JVMS, and is essential for
correct operation of inner classes.

JVMS 4.9.4: "Before that method invokes another instance initialization
method of myClass or its direct superclass on this, the only operation
the method can perform on this is assigning fields declared within
myClass."

class Super
{
  void m() {}
  Super()
  {
    m();
  }
}
class Blah
{
  public static void main(String[] args)
  {
    new Blah().new Inner();
  }
  public String toString()
  {
    return "Blah";
  }

  class Inner extends Super
  {
    void m()
    {
      System.out.println(Blah.this); // should print Blah, not null
    }
  }
}

With Sun's JDK 1.4-beta3, I get these results:

$ javac Blah.java
$ java Blah
null
$ javac -source 1.4 Blah.java
$ java Blah
Blah

Enabling -source 1.4 changes the bytecode emission to set Inner.this$0
before calling the superconstructor, so the polymorphic call to m() does
not find a null reference.


Tom Tromey wrote:
> 
> The constructor for x assigns to this$0 before it invokes super(),
> which is a violation of the JVM spec.  The gij bytecode verifier
> catches this (one of a very few actual verification failures it has
> correctly detected :-).
> 
> This patch attempts to fix the problem.  It works on the above test
> case.  I'm rebuilding libgcj with this.  Assuming the rebuild is fine,
> is this ok to check in?

Hold off on your patch; because the bytecode is legal.  By the way,
compiling the above examples with jikes 1.15 causes the problems with
null, but I am working on a patch for jikes 1.16 which initializes
this$0 before calling the superconstructor, to match the behavior of
javac -source 1.4.

> 
> Tom
> 

-- 
This signature intentionally left boring.

Eric Blake             ebb9@email.byu.edu
  BYU student, free software programmer