Late Binding in Java

Question

I have searched through all the similar questions on late binding on stack overflow, and I would severely disagree with anyone who marks this question as a duplicate. First off, i found this example on another question, but I do not understand how I am supposed to know when something is decided during compile time and when something is decided during run time. Basically, the crux of my question boils down to two things:

• What in this example must bring me to the logical conclusion that one method is late binding and another is early binding

• How do I know when the decision about which version of a method to execute is decided during run-time or compile time in Java

Code:

class A
{
    public void foo()
    {
        System.out.println("Class A");
    }
}

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

public class C
{
    public static void main(String [] args)
    {
        A a=new A();
        B b=new B();
        A ref=null;

        /* 
            early binding  --- calls method foo() of class A and
            decided at compile time
        */ 
         a.foo(); 

        /* early binding --- calls method foo() of class B and
            decided at compile time
        */
          b.foo(); 

        /* late  binding --- --- calls method foo() of class B and
           decided at Run time
     */ 
        ref=b;
        ref.foo(); }
}

Answer 1

Wrong on all counts. The method to be called is decided at runtime, in every case here, based on the runtime type of the object. The only decisions made at compile time are for calls to final, private, or static methods, or choices among a set of overloaded methods (which could still lead to runtime choices if the overloaded methods are not final, private, or static.)

Answer 2

All the answers here are mostly correct, but there is one key point missing regarding late binding in Java.
Java does not perform "by the book" late binding if we go by the definition of late binding. Late binding in its book definition form means that the compiler should perform no argument checks, no type checks on a method call and should leave it all to the runtime - because possibly the compiler does not have access to the method implementation code (for example in COM programming). Java however at compile time does verify, even in a polymorphic scenario, that the method being called and the method signature does exist somewhere in the type hierarchy of the expression that qualifies the method. So for example, lets say I call a method foo1 on ref that does not exist in either A or B:

A ref=null;
ref=new B();
ref.foo1();
//This will not compile in Java, because java will check at compile time
//for the method foo1 in the type hierarchy of A, which is the type of the 
// variable ref at compile time.
//In pure late binding, however this would pass compilation and 
//throw an error at runtime.

In a pure late binding scenario, the determination of whether the method foo1() exists or not with the right number of arguments is made purely at runtime. However in Java, there is some level of checking done at compile time, to ensure that the method with the right number of arguments does exist somewhere in the type hierarchy.
The only time that I think Java does perform pure late binding is if one uses reflection to call a method. What Java does is better termed as dynamic dispatch rather than late binding, but everyone calls it late binding in Java and hence there is confusion.