• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Overloaded Methods in Java are early binded or late binded

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Amar Shrivastava
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Bartender
Posts: 1845
10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)?
 
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Sabarish Sasidharan
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1845
10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 89
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1845
10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
>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.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
girl power ... turns out to be about a hundred watts. But they seriuosly don't like being connected to the grid. Tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic