This week's giveaway is in the EJB and other Java EE Technologies forum.
We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line!
See this thread for details.
The moose likes Java in General and the fly likes Overloaded Methods in Java are early binded or late binded Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Overloaded Methods in Java are early binded or late binded" Watch "Overloaded Methods in Java are early binded or late binded" New topic
Author

Overloaded Methods in Java are early binded or late binded

Amar Shrivastava
Greenhorn

Joined: Oct 17, 2005
Posts: 13
Hi All

During my recent interviews I was asked about Polymorphism and early binding and late binding. Every time I said that overloaded methods implementations are binded dynamically during runtime until the method is static or final(private are implictly final). But every time I was told by the interviewers that overloaded methods are early binded.
Could you please suggest what is correct with overloaded methods and Why?
[ October 17, 2005: Message edited by: Amar Shrivastava ]
Sabarish Sasidharan
Ranch Hand

Joined: Aug 29, 2002
Posts: 73
If you are talking about overloading, then yes, there is no dynamic binding involved... So i can agree with your interviewers. On the other hand overriding requires runtime binding.


Sab<br /> <br />Perfection does not come from belief or faith. Talk does not count for anything. Parrots can do that. Perfection comes through selfless work.<br />Swami Vivekananda
Amar Shrivastava
Greenhorn

Joined: Oct 17, 2005
Posts: 13
But how could you ever say that the overloaded method will not be overridden in the subclasses.

Let's say:


In this case looking at class A alone which does not no that it has a sub class and the class Client uses a class A reference and calls a method x.
Now how could this be resolved at compile time.
[ October 18, 2005: Message edited by: Amar Shrivastava ]
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11278
    
  59

Moved to Java in General (Intermediate). I am not sure that it belongs there, but that is where your other copy of the same question is. In future, please Carefully Choose One Forum.


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24166
    
  30

Originally posted by Amar Shrivastava:
Now how could this be resolved at compile time.


The decision about which of the three overloaded signatures applies is made at compile time. Normal runtime polymorphism applies for the overridden methods with a given signature.

In your example, there is both overloading and overriding -- both early and late binding. But if the interviewers are asking about overloaded methods, then you should just answer based on that -- not based on other irrelevant details.


[Jess in Action][AskingGoodQuestions]
Stefan Evans
Bartender

Joined: Jul 06, 2005
Posts: 1016
Your example is a good one for late binding.

Here is one that demonstrate early binding.
Late binding is used when calling a method on an object.
Early binding is used when you call a method with an object as a parameter.


That should demonstrate the difference with overloading methods and early binding.
Amar Shrivastava
Greenhorn

Joined: Oct 17, 2005
Posts: 13
There is a little more confusion now!!!

What is meant by "Binding"?

Is it only method signature resolution or is it the binding of method signature with actual method implementaion(i.e. method body)?
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
Originally posted by Amar Shrivastava:
There is a little more confusion now!!!

What is meant by "Binding"?

Is it only method signature resolution or is it the binding of method signature with actual method implementaion(i.e. method body)?


Both. Early binding (i.e. at compile time) ensures that the a method call matches with a given method signature. Late binding (i.e. at run time) determines which implementation to use if the method is overridden by any subclasses.

Layne


Java API Documentation
The Java Tutorial
Sabarish Sasidharan
Ranch Hand

Joined: Aug 29, 2002
Posts: 73
Originally posted by Amar Shrivastava:
But how could you ever say that the overloaded method will not be overridden in the subclasses.
[ October 18, 2005: Message edited by: Amar Shrivastava ]

Overloading of overridden methods does not need late binding.
Amar Shrivastava
Greenhorn

Joined: Oct 17, 2005
Posts: 13
Early binding is not only method signature resolution at compile time .It also binds the exact method implementation (method body) with the method call at compile time. This can only happen if the compiler can determine( looking at the modifiers associated with the member of the class) that there would be no ambiguity at runtime, no matter which type of object being referred by the reference.
So, if the above thought is right :roll: then early binding should occur with only private, static and final methods. Hence, early binding has nothing to do with overloaded methods. It is the modifier which helps determine whether it is early binding or late binding.

[ October 18, 2005: Message edited by: Amar Shrivastava ]
[ October 18, 2005: Message edited by: Amar Shrivastava ]
Stefan Evans
Bartender

Joined: Jul 06, 2005
Posts: 1016
Overloading: lets you define one method multiple times with different signatures (ie different parameters to the method)
Overriding: lets you define multiple implementations of methods in different classes. The methods all have the same signature. It chooses which to use at runtime depending on the class at runtime.

There are two issues here
1 - what is the signature of the method to call (bound at compile time)
2 - which implementation of this method is called (bound at runtime)

Thus overloaded methods are ALWAYS bound at compile time.
The late binding applies to overridden methods only.

If an overloaded method is also overridden, you have both early and late binding. The signature of the method is bound early (ie which of the overloaded methods do we call)
The implementation is done using late binding. We KNOW the signature of the method to call, but we don't know the type of the object that we will be calling the method on until runtime.
[ October 18, 2005: Message edited by: Stefan Evans ]
Rob Acraman
Ranch Hand

Joined: Dec 03, 2000
Posts: 89
Sorry Stefan, I'm with Amar.

You are right that issue 1 (determining the signature of a method to call) has to be performed by the compiler, but that's not early binding.

Early binding means the compiler effectively hard-codes in the .class file which implementation of that signature is going to be called. As Amar says, that is only possible with static/final/private methods, since these methods cannot be overridden.

So, coming to Issue 2 (which implementation to call): if the method is static/final/private, then early binding is used, otherwise late binding.

To go back to Amar's original question, early/late binding has NOTHING to do with overloading, for the simple reason that overloaded methods have nothing to do with eachother.
Rob Acraman
Ranch Hand

Joined: Dec 03, 2000
Posts: 89
I just looked at Thinking In Java, Chapter 7

All method binding in Java uses late binding unless the method is static or final (private methods are implicitly final). This means that ordinarily you don�t need to make any decisions about whether late binding will occur�it happens automatically. Feedback

Why would you declare a method final? As noted in the last chapter, it prevents anyone from overriding that method. Perhaps more important, it effectively �turns off� dynamic binding, or rather it tells the compiler that dynamic binding isn�t necessary. This allows the compiler to generate slightly more efficient code for final method calls. However, in most cases it won�t make any overall performance difference in your program, so it�s best to only use final as a design decision, and not as an attempt to improve performance. Feedback
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24166
    
  30

Except ... that some very respectable members of the OO community like to call method overloading "compile-time polymorphism" and overriding (of course) "runtime polymorphism", so that the applicability and parallelism of the "early" and "late binding" terms is pretty obvious. I don't think Stefan is off base at all here.
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
Originally posted by Ernest Friedman-Hill:
Except ... that some very respectable members of the OO community like to call method overloading "compile-time polymorphism" and overriding (of course) "runtime polymorphism", so that the applicability and parallelism of the "early" and "late binding" terms is pretty obvious. I don't think Stefan is off base at all here.


Within the context of Java is it not true that final, static and private methods are early-binded and all others late-binded? I don't see how calling overloading compile-time and overriding runtime changes this.
Stefan Evans
Bartender

Joined: Jul 06, 2005
Posts: 1016
>Rob Acraman :>Sorry Stefan, I'm with Amar.
Actually I think we share the same opinion. I just didn't go as far as you.
You are entirely correct with regard to issue two.

The point of my post was to try and clarify that overriding and overloading had two different sets of rules with regards to "binding"

Just to contribute another 2 cents:

>Within the context of Java is it not true that final, static and private
>methods are early-binded and all others late-binded?
Perfectly true.
But this statement applies only to method overriding.
It does not apply to overloading. In fact as mentioned above, technically early/late binding has nothing to do with overloaded methods.


If we define binding as "determine which of the available options to use", then we can apply the concept of binding to both overriding and overloading.
With regard to overloading, the decision is which method signature to use (within one class)
With regard to overriding, the decision is which class' implementation of a particular method to use. (over the entire class hierarchy). At this point the signature of the method must be known.
"Early binding" happens at compile time.
"Late binding" happens at runtime.

By that definition of binding,
overriding is ALWAYS bound at compile time (early binding)
overloading: if the method is final/static/private: bound at compile time (early)
else bound at runtime (late)

Thats how I think of it anyway.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
What is interesting to me is compile time dependencies. If I call a method on another object, do I have to have the concrete implementation class of that object at compile time? If I work with a List the answer is no. If I create a new ArrayList the answer is yes.

This is important to me because I often want to extend systems by adding new implementations of interfaces. I can accomplish this without thinking about early or late binding, though that's likely exactly the issue under the covers.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Overloaded Methods in Java are early binded or late binded
 
Similar Threads
Overloaded Methods in Java are early binded or late binded
Late binding v/s Dynamic
virtual methods
Overloading and early binding
Overloading vs Overriding