Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Dynamic Binding  RSS feed

 
vijay kumarg
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I am not wrong, I have studied in 'Thinking in Java' as " Every method call in java is dynamic binded ".But what is the need for dynamic binding for calling a method of an object which don't have any super type( abstract class or inteface).Wouldnot it be possible for linking at compile time only for this type of calls ?
Am I following the correct trial ?
 
fred rosenberger
lowercase baba
Bartender
Posts: 12542
48
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The only class that does not have a supertype is the Object class. If you don't explicitly extend some other class, you extend the Object class.
 
vijay kumarg
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear Fred,
You meant to tell, the condition that 'every class is a sub type of Object' only forces the use of dynamic binding during a method call or there exist any other rule.
Fred,please note in my first post "object" refers to object of an arbitrary class not Object(which is the superclass of all java classes)
In C++ the concept of compile time binding exists(subject to correction)
then why 'only dynamic binding' exists in Java?

[ January 24, 2007: Message edited by: vijayk gopu ]
 
fred rosenberger
lowercase baba
Bartender
Posts: 12542
48
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All I meant was that I believe your statement is flawed.
...calling a method of an object which don't have any super type
The only kind of object that doesn't have a supertype is an Object.

Granted, it is early, and I may not be understanding you.
 
vijay kumarg
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fred,
Sorry for not making the topic clearer.
My doubt is whether compile time binding exists in java?
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by vijayk gopu:

My doubt is whether compile time binding exists in java?


For static methods, yes. But all other Java methods are "virtual" (in the C++ sense), at least in theory.

Remember that Java code is run by a "smart" virtual machine that generally includes some kind of a just-in-time native compiler; this compiler gets a chance to look at the code more closely at runtime and can, indeed, turn some method calls into statically-bound calls, so that no dynamic lookup actually happens. But that's an implementation detail: in theory, every call to a non-static method call is dynamic.
 
vijay kumarg
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Fred and Ernest!
I am happy except loosing a bet
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For static methods, yes. But all other Java methods are "virtual" (in the C++ sense), at least in theory.


Do final methods get any special treatment? I know the compiler won't let you override them, but don't know if it wires up anything different on the call.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:


Do final methods get any special treatment? I know the compiler won't let you override them, but don't know if it wires up anything different on the call.


I was thinking about final methods when I wrote the above, and wondered if I should mention them or not. It turns out that for final methods, the Java compiler does nothing special at all; the method call is compiled to the same bytecodes as it would be for a non-final method. So my answer holds.


Now, the bytecode does contain the type of the reference through which the method was called. The truth is that it would be foolish for any VM not to note final methods and classes and use these to turn virtual calls into direct nonvirtual ones. The original VM spec actually described the VM's mechanism for doing something similar with interface method calls, turning them into standard, cheaper virtual calls at runtime. You can bet HotSpot turns virtual calls to final methods into static calls at runtime.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In comparison, calls to private methods are treated a little differently by the compiler - they're called with invokespecial rather than invokevirtual. Which, from skimming the description, seems to mean less method lookup for the JVM. But I agree with EFH - regardless of what the compiler does here, HotSpot has enough info to convert both final and private method calls into nonvirtual calls.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You guys rock.

In previous lives and languages I dug into that level of detail, but nowadays I don't have enough concious hours in the day. Thanks!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!