Difference between Dynamic Binding & Static Binding in Java Dynamic Binding or Late Binding Dynamic Binding refers

to the case where compiler is not able to resolve the cal l and the binding is done at runtime only. Let's try to understand this. Suppose we have a class named 'SuperClass' and another class named 'SubClass' extends i t. Now a 'SuperClass' reference can be assigned to an object of the type 'SubCla ss' as well. If we have a method (say 'someMethod()') in the 'SuperClass' which we override in the 'SubClass' then a call of that method on a 'SuperClass' refer ence can only be resolved at runtime as the compiler can't be sure of what type of object this reference would be pointing to at runtime. ... SuperClass superClass1 = new SuperClass(); SuperClass superClass2 = new SubClass(); ... superClass1.someMethod(); // SuperClass version is called superClass2.someMethod(); // SubClass version is called .... Here, we see that even though both the object references superClass1 and superCl ass2 are of type 'SuperClass' only, but at run time they refer to the objects of types 'SuperClass' and 'SubClass' respectively. Hence, at compile time the compiler can't be sure if the call to the method 'som eMethod()' on these references actually refer to which version of the method - t he super class version or the sub class version. Thus, we see that dynamic binding in Java simply binds the method calls (inherit ed methods only as they can be overriden in a sub class and hence compiler may n ot be sure of which version of the method to call) based on the actual object ty pe and not on the declared type of the object reference. Static Binding or Early Binding If the compiler can resolve the binding at the compile time only then such a bin ding is called Static Binding or Early Binding. All the instance method calls ar e always resolved at runtime, but all the static method calls are resolved at co mpile time itself and hence we have static binding for static method calls. Beca use static methods are class methods and hence they can be accessed using the cl ass name itself (in fact they are encourgaed to be used using their correspondin g class names only and not by using the object references) and therefore access to them is required to be resolved during compile time only using the compile ti me type information. That's the reason why static methods can not actually be ov erriden. Read more - Can you override static methods in Java? Similarly, access to all the member variables in Java follows static binding as Java doesn't support (in fact, it discourages) polymorphic behavior of member va riables. For example:class SuperClass{ ... public String someVariable = "Some Variable in SuperClass"; ... } class SubClass extends SuperClass{ ...

public String someVariable = "Some Variable in SubClass"; ... } ... ... SuperClass superClass1 = new SuperClass(); SuperClass superClass2 = new SubClass(); System.out.println(superClass1.someVariable); System.out.println(superClass2.someVariable); ... Output:Some Variable in SuperClass Some Variable in SuperClass We can observe that in both the cases, the member variable is resolved based on the declared type of the object reference only, which the compiler is capable of finding as early as at the compile time only and hence a static binding in this case. Another example of static binding is that of 'private' methods as they ar e never inherited and the compile can resolve calls to any private method at com pile time only. =================================================== Question: Can you override Static Methods in Java? Answer: Well... the answer is NO if you think from the perspective of how an ove rriden method should behave in Java. But, you don't get any compiler error if yo u try to override a static method. That means, if you try to override, Java does n't stop you doing that; but you certainly don't get the same effect as you get for non-static methods. Overriding in Java simply means that the particular meth od would be called based on the run time type of the object and not on the compi le time type of it (which is the case with overriden static methods). Okay... an y guesses for the reason why do they behave strangely? Because they are class me thods and hence access to them is always resolved during compile time only using the compile time type information. Accessing them using object references is ju st an extra liberty given by the designers of Java and we should certainly not t hink of stopping that practice only when they restrict it :-) Example: let's try to see what happens if we try overriding a static method:class SuperClass{ ...... public static void staticMethod(){ System.out.println("SuperClass: inside staticMethod"); } ...... }

public class SubClass extends SuperClass{ ...... //overriding the static method public static void staticMethod(){ System.out.println("SubClass: inside staticMethod"); } ...... public static void main(String []args){ ...... SuperClass superClassWithSuperCons = new SuperClass(); SuperClass superClassWithSubCons = new SubClass(); SubClass subClassWithSubCons = new SubClass(); superClassWithSuperCons.staticMethod(); superClassWithSubCons.staticMethod(); subClassWithSubCons.staticMethod(); ... } } Output:SuperClass: inside staticMethod SuperClass: inside staticMethod SubClass: inside staticMethod Notice the second line of the output. Had the staticMethod been overriden this l ine should have been identical to the third line as we're invoking the 'staticMe thod()' on an object of Runtime Type as 'SubClass' and not as 'SuperClass'. This confirms that the static methods are always resolved using their compile time t ype information only.