This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Beginning Java and the fly likes Can anyone explain executing at runtime vs compile? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Can anyone explain executing at runtime vs compile?" Watch "Can anyone explain executing at runtime vs compile?" New topic
Author

Can anyone explain executing at runtime vs compile?

Jay Dilla
Ranch Hand

Joined: Aug 12, 2004
Posts: 201
I'm studying about overloading and how it affects whether or not the reference is used or the object is used.
example:



which would work verus



which wouldn't work because Animals eat method doesn't take strings (it doesn't take anything) but the subclass horses eat method does .

Because one would execute at runtime instead of at compile time. Can someone explain the main differences between the two and why some procedures run at one time and not the other?

[ March 21, 2007: Message edited by: Jay Dilla ]
[ March 21, 2007: Message edited by: Jay Dilla ]
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by Jay Dilla:
...ah.eat; ...

This references a field. Do you mean to call a method, for example, ah.eat();?


"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
Jay Dilla
Ranch Hand

Joined: Aug 12, 2004
Posts: 201
Originally posted by marc weber:

This references a field. Do you mean to call a method, for example, ah.eat();?



yes my bad
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Can you post the code for Animal and Horse?
Jay Dilla
Ranch Hand

Joined: Aug 12, 2004
Posts: 201
Originally posted by marc weber:
Can you post the code for Animal and Horse?




marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

All "execution" is at runtime. So it's not a question of when methods are "executed," but when methods are "bound." In other words, when a method call is "connected" to a method body.

In Java, all method binding is "dynamic" unless the method is static, private, or final. Dynamic (which is also called "late" or "runtime") binding means that the method body is selected at runtime based on the true runtime type of the object.

So in both of your examples, the eat method would be resolved at runtime. The problem is that your reference type is Animal, and Animal's only eat method does not take any arguments. So when you use that reference to try to call eat with a String argument, you will get a compiler error because Animal has no such method.

For more details, see the section Method-call binding from Thinking in Java.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Also notice that the two eat methods are totally different methods. For the compiler, a method is identified by its signature (that is, name + argument types), not only its name. So the compile error is exactly the same you'd get if the methods were named differently.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

I think method 'binding' is done at compile time. Object binding is done at runtime. So at compile time the compiler knows what method it is calling, it just does not know on which object since objects do not exist at compile time.

I hope my terms are correct. But I know the Java decides which method at compile time. For instance



Eventhough the object type is really an Integer, this fact is not known until runtime. But by then the choice of method to call is already determined based on the 'type' of the variable passed into the call. The variable is 'var' and its type is 'Object.'
[ March 21, 2007: Message edited by: Mr. C Lamont Gilbert ]
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by Mr. C Lamont Gilbert:
I think method 'binding' is done at compile time. Object binding is done at runtime. So at compile time the compiler knows what method it is calling, it just does not know on which object since objects do not exist at compile time.

I hope my terms are correct...

In your example, you are using explicit casts to "assure" the compiler of the parameter's runtime type, and therefore which overloaded method to call. But this is quite different than selecting an overridden method body to invoke at runtime.

As Eckel says in Thinking in Java, "Connecting a method call to a method body is called binding." And "all method binding in Java uses late [runtime] binding unless the method is static or final (private methods are implicitly final)."

In a more general sense, "binding refers to the association of values with identifiers." (Wikipedia - Dynamic Binding.) In this case, the identifier is a method signature (the method's name and its argument list), so the compile-time resolution of which overloaded method to call is really just selecting the proper identifier. The binding occurs when that identifier is associated with a body to invoke, which can only happen at runtime (for non-final instance methods).
[ March 21, 2007: Message edited by: marc weber ]
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

My cast do not give the compiler anymore information about runtime type than it already had. Which is none.



In fact this example is a bit misleading. All the compiler knows is its calling a version of method #2 or a version of method #1.

In this example 'binding' is the association of the variable ac to the class AClass. This association occurs at runtime. AClass could have several children and that is not determined until runtime.



The choice to call AClass, BClass, or CClass's method definitions is called 'binding.'
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by Mr. C Lamont Gilbert:
My cast do not give the compiler anymore information about runtime type than it already had. Which is none...

Explicit casts give the compiler your assurance that the runtime type will be what you indicate. Without this information, the code would not compile (if downcasting is required). Of course, the JVM can't know until runtime whether this information is correct, and a runtime exception will be thrown if the information turns out to be wrong.
Originally posted by Mr. C Lamont Gilbert:
... The choice to call AClass, BClass, or CClass's method definitions is called 'binding.'

Yes, and this is dynamic (runtime) binding. The question seems to be whether selecting a method call at compile time (based on argument types) constitutes "binding" (for non-final instance methods), and I don't think this falls under the definitions I've seen.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Originally posted by marc weber:

Explicit casts give the compiler your assurance that the runtime type will be what you indicate. Without this information, the code would not compile (if downcasting is required). Of course, the JVM can't know until runtime whether this information is correct, and a runtime exception will be thrown if the information turns out to be wrong.


The compiler couldn't care less about runtime types.

Originally posted by marc weber:
Yes, and this is dynamic (runtime) binding. The question seems to be whether selecting a method call at compile time (based on argument types) constitutes "binding" (for non-final instance methods), and I don't think this falls under the definitions I've seen.


True. I want to highlight the choices that are made at compile time, vs. those that are made at runtime. This also has a lot to do with what the compiler is capable of inlining. It also affects your ability to modify classes after other classes have been compiled. You can add all the new child classes you want without recompiling. But if you add a new method with a more narrow signature, then compile the callee you might be confused when the caller does not call it.
Jay Dilla
Ranch Hand

Joined: Aug 12, 2004
Posts: 201
thanks guys
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
Note that not all languages are like this. Java has dynamic binding but static typing.

Some languages do not do any type checking until run-time. The one I'm most familiar with is JavaScript (which is not all that much like Java, despite the name). [later] maybe a bad example, as JavaScript is usually not compiled at all.
[ March 22, 2007: Message edited by: Peter Chase ]

Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by Mr. C Lamont Gilbert:
... The compiler couldn't care less about runtime types...

But in cases of downcasting, the compiler does care what you tell it the runtime type will be. Or to quote Eckel again, "the compiler doesn't allow you to perform a downcast assignment without using an explicit cast." That's all I'm saying.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

I hear what your saying. But this has nothing to do with runtime.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Can anyone explain executing at runtime vs compile?
 
Similar Threads
Whether the derived class method can throw a exception while overriding?
Polymorphism in Overloaded and Overridden Methods
Polymorphism
If i want to report a bug
Overloading/over riding book doubt in Bertbates book page num 310