Can anyone explain executing at runtime vs compile?

[Jay Dilla]

I'm studying about overloading and how it affects whether or not the reference is used or the object is used.
example:

 Animal ah = new Horse ();
       ah.eat();

which would work verus

 Animal ah2 = new Horse();
       ah2.eat("carrots");

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]

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

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

[Jay Dilla]

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]

Can you post the code for Animal and Horse?

[Jay Dilla]

Originally posted by marc weber:
Can you post the code for Animal and Horse?

  
public class Animal {
 public void eat(){
  System.out.println("Generic Animal eating");
    }
  }
 
public class Horse extends Animal {
 public void eat() {
  System.out.println("Horse eating");
   }
 public void eat(String s){
  System.out.println("Horse eating" + s);
   }
}
 

 

[marc weber]

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]

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.

[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. But I know the Java decides which method at compile time. For instance

class AClass {
 public void call(Object o){}; //method #1
 public void call(Integer o){};//method #2
}
 
Object var = new Integer(4);
AClass ac = new AClass();
ac.call(var); //calls method #1
ac.call(new Object());//calls method #1
ac.call( (Object) new Integer(0));//calls method #1
ac.call(new Integer(0));//calls method #2
ac.call((Integer)var);//calls method #2
 

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]

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]

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

class AClass {
 public void call(Object o){}; //method #1
 public void call(Integer o){};//method #2
}
 
Object var = new Integer(4);
AClass ac = new AClass();
ac.call(var); //calls method #1
ac.call(new Object());//calls method #1
ac.call( (Object) new Integer(0));//calls method #1
ac.call(new Integer(0));//calls method #2
ac.call((Integer)var);//calls method #2

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.

class BClass extends AClass {
 public void call(Object o){}; //method #1b
 public void call(Integer o){};//method #2b
}
class CClass extends BClass {
 public void call(Object o){}; //method #1c
 public void call(Integer o){};//method #2c
}

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

[marc weber]

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]

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]

thanks guys

[Peter Chase]

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 ]

[marc weber]

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]

I hear what your saying. But this has nothing to do with runtime.