Java, Static Method Binding and Generics all rolled up with some Method Overloading

Question

So as the title implies my question is a bit odd and complicated. I know what I'm about to do breaks all the rules of "good" programming practices but hey, what's life if we don't live a little?

So what I did was create the following program. (Note this was part of a larger experiment to really try and understand generics so some of the function names maybe a bit out of order)

import java.util.*;

public class GenericTestsClean 
{
    public static void test2()
    {
        BigCage<Animal> animalCage=new BigCage<Animal>();
        BigCage<Dog> dogCage=new BigCage<Dog>();
        dogCage.add(new Dog());
        animalCage.add(new Cat());
        animalCage.add(new Dog());
        animalCage.printList(dogCage);
        animalCage.printList(animalCage);
    }


    public static void main(String [] args)
    {
        //What will this print
        System.out.println("\nTest 2");
        test2();
    }

}

class BigCage<T> extends Cage<T>
{

    public static <U extends Dog> void printList(List<U> list)
    {
        System.out.println("*************"+list.getClass().toString());
        for(Object obj : list)
            System.out.println("BigCage: "+obj.getClass().toString());
    }

}
class Cage<T> extends ArrayList<T>
{
    public static void printList(List<?> list)
    {
        System.out.println("*************"+list.getClass().toString());
        for(Object obj : list)
            System.out.println("Cage: "+obj.getClass().toString());
    }
}

class Animal
{
}
class Dog extends Animal
{
}
class Cat extends Animal
{
}

Now what is confusing me is that this compiles fine with javac 1.6.0_26 but when I run it I get the following class cast exception:

Test 2
*************class BigCage
BigCage: class Dog
*************class BigCage
Exception in thread "main" java.lang.ClassCastException: Cat cannot be cast to Dog
        at BigCage.printList(GenericTestsClean.java:31)
        at GenericTestsClean.test2(GenericTestsClean.java:13)
        at GenericTestsClean.main(GenericTestsClean.java:21)

A number of things to note here:

1. The two printList are NOT overriding but overloading each other as expected(They have different types because the generic types of their arguments are different). This can be verified by using the @Override annotation
2. Changing the void printList(List<?>) method in class Cage to be non-static generates an appropriate compile time error
3. Changing the method void <U extends Dog> printList(List<U>) in class BigCage to void <U> printList(List<U>) generates an appropriate error.
4. In main() calling printList() through the class BigCage (ie BigCage.printList(...)) generates the same runtime error
5. In main() calling printList() through the class Cage (ie Cage.printList(...)) works as expected only calling the version of printList in Cage
6. If I copy the definition for printList(List<?>) to class BigCage from class Cage, which will hide the definition in class Cage, I get the appropriate compiler error

Now if I had to take a shot in the dark as to what is going on here, I'd say the compiler is screwing up because it's working in multiple phases: Type Checking and Overloaded Method Resolution. During the type checking phase we get through the offending line because class BigCage inherited void printList(List<?>) from class Cage which will match any old List we throw at it, so sure we have a method that will work. However once it comes time to resolve with method to actually call we have a problem due to Type Erasure which causes both BigCage.printList and Cage.printList to have the exact same signature. This means when compiler is looking for a match for animalCage.printList(animalCage); it will choose the first method it matches (and if we assume it starts at the bottom with BigCage and works its why up to Object) it'll find void <U extends Dog> printList(List<U>) first instead of the correct match void printList(List<?>)

Now for my real question: How close to the truth am I here? Is this a known bug? Is this a bug at all? I know how to get around this problem, this is more of an academic question.

**EDIT**

As few people have posted below, this code will work in Eclipse. My specific question deals with javac version 1.6.0_26. Also, I'm not sure if I completely agree with Eclipse in this case, even though it works, because adding a printList(List<?>) to BigCage will result in a compile time error in Eclipse and I can't see reason why it should work when the same method is inherited verses manually added (See Note 6 above).

Answer 1

Consider this trivial problem:

class A
{
    static void foo(){ }
}
class B extends A
{
    static void foo(){ }
}
void test()
{
    A.foo();
    B.foo();
}

Suppose we remove the foo method from B, and we only recompile B itself, what could happen when we run test()? Should it throw linkage error because B.foo() is no found?

According to JLS3 #13.4.12, removing B.foo doesn't break binary compatibility, because A.foo is still defined. This means, when B.foo() is executed, A.foo() is invoked. Remember, there's no recompilation of test(), so this forwarding must be handled by JVM.

Conversely, let's remove foo method from B, and recompile all. Even though compiler knows statically that B.foo() actually means A.foo(), it still generate B.foo() in the bytecode. For now, JVM will forward B.foo() to A.foo(). But if in future B gains a new foo method, the new method will be invoked at runtime, even if test() isn't recompiled.

In this sense, there is a overriding relation among static methods. When compile sees B.foo(), it must compile it to B.foo() in bytecode, regardless whether B has a foo() today.

In your example, when compiler sees BigCage.printList(animalCage), it correctly infer that it's actually calling Cage.printList(List<?>). So it needs to compile the call into bytecode as BigCage.printList(List<?>) - the target class must be BigCage here instead of Cage.

Oops! Bytecode format hasn't been upgrade to handle method signature like that. Generics information are preserved in bytecode as auxilary information, but for method invocation, it's the old way.

Erasure happens. The call is actually compiled into BigCage.printList(List). Too bad BigCage also has a printList(List) after erasure. At runtime, that method is invoked!

This problem is due to the mismatch between Java spec and JVM spec.

Java 7 tightens up a little; realizing bytecode and JVM can't handle such situations, it no longer compiles your code:

error: name clash: printList(List) in BigCage and printList(List) in Cage have the same erasure, yet neither hides the other

Another fun fact: if the two methods have different return types, your program will work correctly. This is because in byte code, method signature includes return type. So there is no confusion between Dog printList(List) and Object printList(List). See also Type Erasure and Overloading in Java: Why does this work? This trick is only allowed in Java 6. Java 7 forbids it, probably for reasons other than technical ones.

Answer 2

This is not a bug. The method is static. You cannot override static methods, you only hide them.

When you call "printList" on bigCage, you really are calling printList on BigCage class and not the object, which will always call your static method declared in BigCage class.