# Friday, 04 November 2011
« Java Method Overriding Is FUBAR Part 1 o... | Main | Java Method Overriding Is FUBAR Part 3 o... »
Java Method Overriding Is FUBAR Part 2 of ∞

In part 1 of this series I argued that the spec is broken, now I'll show the first example where the reference implementation does not implement the spec.

package p1;

public class A
{
  { foo(); }
  public void foo() {
    System.out.println("A.foo");
  }
  public static void main(String[] args) {
    new p3.C();
  }
}

package p2;

public class B extends p1.A
{
  { foo(); }
  void foo() {
    System.out.println("B.foo");
  }
}

package p3;

public class C extends p2.B
{
  void foo() {
    System.out.println("C.foo");
  }
}

(If you want to compile this with javac you'll need to first compile it with a version of A that does not have a public foo method and then change A and just recompile A.)

Now the question is does C.foo override B.foo? According to the spec it does not, but when you compile this with javac from JDK 7 (because the class file version needs to be 51 to get the new behavior) and run it you get:

C.foo
C.foo

So C.foo overrides both A.foo and B.foo.

Friday, 04 November 2011 07:27:31 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
Name
E-mail
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Answer:  
Comment (HTML not allowed)  

Live Comment Preview