Binding of variables and methods at compile time and runtime

[pagano monello]

Hi,
I cannot understand a concept illustrated on Mala Gupta "OCA Java SE7 Certification Guide" at the paragraph 6.6.2 entitled “Binding of variables and methods at compile time and runtime” (pag. 329 on).

I report below the code used to illustrate the concept:

public class Employee {
    String name = "Employee";
    void printName(){
        System.out.println(name);
    }
}

public class Programmer extends Employee {
    String name = "Programmer";
    void printName(){
        System.out.println(name);
    }
}

public class Office1 {
    public static void main(String [] a){
        Employee emp = new Employee();
        Employee programmer = new Programmer();   
        System.out.println(emp.name);
        System.out.println(programmer.name);       //***
        emp.printName();
        programmer.printName();
    }
}

Here it is the output genereted by the code:
Employee
Employee
Employee
Programmer

What I cannot understand is the output generated by line ***.

The Author says that:

The type of variable programmer is Employee. Because the variables are bound at compile time, the type of the object that's referenced by the variable emp doesn't make a difference. programmer.name will access the variable name defined in the class Employee.

Umm unfortunately I really don't understand this explanation.

Can anyone help me? I would be grateful, because I think that this is a really important point.

Thank you in advance.

[Paul Anilprem]

Yes, it is a very important concept. Before you can understand the whole statement, you need know what "binding" means. Do you understand what it means?

[Sergej Smoljanov]

this is important point.
When you use type of parent, even if you use object of children when you try access variable, you will get variable from type reference of which you use (if access modifier admit (for example you will not able get private variable from different (not inner) class directly))
if you change

public class Employee {
    void printName(){
        System.out.println(name);
    }
}

and use it
System.out.println(emp.name);
System.out.println(programmer.name);
you get compiler error.
if you change Employee programmer = new Programmer(); to Programmer programmer = new Programmer(); you get variable from Programmer,
but if you use Employee programmer = new Programmer(); you get variable from Employee.
This is rule.

[pagano monello]

Hi Paul,
thank you for you answer. You are totally right!!!

In effect I am still confused about the meaning of the term "binding"; I guess that it could stand for "decide", "establish", "determine", but I am not sure at all.

Also, why the author says:

the type of the object that's referenced by the variable emp doesn't make a difference

I do cannot understand the sense of this observation.

[Henry Wong]

pagano monello wrote:
Also, why the author says:

the type of the object that's referenced by the variable emp doesn't make a difference

I do cannot understand the sense of this observation.

You need to keep stuff in context ... Was the author referring to accessing (hidden) fields? Or calling (overridden) instance methods?

Henry

[Sergej Smoljanov]

the type of the object that's referenced by the variable emp doesn't make a difference

Employee emp =
Employee programmer =
it is same type, is statement you quote make more understandable to you if you change emp to programmer?

[Paul Anilprem]

pagano monello wrote:Hi Paul,
thank you for you answer. You are totally right!!!

In effect I am still confused about the meaning of the term "binding"; I guess that it could stand for "decide", "establish", "determine", but I am not sure at all.

Also, why the author says:

the type of the object that's referenced by the variable emp doesn't make a difference

I do cannot understand the sense of this observation.

You are correct about binding. It just means a decision. A decision about which member will be accessed if there are multiple members by the same name (or signature in case of methods) accessible. In case of variables, static methods, and private instance methods, this decision is made by the compiler. Why? Nothing special here. It is a rule of Java language. The compiler will decide which member will be used by an expression. The JVM simply uses that particular member as per compiler's decision. How does the compiler decide? Compiler has no knowledge about the actual objects referred to by a variable, right? (Because actual objects are created by by the JVM at run time.) Compiler does have an fair idea but it doesn't know that for sure. So obviously, it cannot decide based on the object type. All it is left with is the variable type.

So my question to you is this: Do you know what "type of variable" and "type of an object referred to by a variable" means?

[pagano monello]

Hi Sergej.
Thank you, really.

I guess I have understood, or I am a little closer to understand. I think that the key point is this sentence you wrote to me:

When you use type of parent, even if you use object of children when you try access variable, you will get variable from type reference of which you use

Thank you.

[pagano monello]

Thank you Paul for your last reply.
Sure, I know the difference between "type of variable" and "type of an object referred to by a variable"; anyway I guess I am not used enough to manage this stuff yet.

What is still quite difficult to understand is the difference in what it happens at compile time and what at runtime.

I think that I must to be patient, and reason about it.

[pagano monello]

Ah wow, I re-read slowly this piece of post:

In case of variables, static methods, and private instance methods, this decision is made by the compiler. Why? Nothing special here. It is a rule of Java language. The compiler will decide which member will be used by an expression. The JVM simply uses that particular member as per compiler's decision. How does the compiler decide? Compiler has no knowledge about the actual objects referred to by a variable, right? (Because actual objects are created by by the JVM at run time.) Compiler does have an fair idea but it doesn't know that for sure. So obviously, it cannot decide based on the object type. All it is left with is the variable type.

So I may have understood: in this case, the type of the variable programmer.name is decided by the compiler; anyway the compiler doesn't know which is the actual object, then it lets the variable type.

Thank you, really.

[Paul Anilprem]

pagano monello wrote:Ah wow, I re-read slowly this piece of post:

In case of variables, static methods, and private instance methods, this decision is made by the compiler. Why? Nothing special here. It is a rule of Java language. The compiler will decide which member will be used by an expression. The JVM simply uses that particular member as per compiler's decision. How does the compiler decide? Compiler has no knowledge about the actual objects referred to by a variable, right? (Because actual objects are created by by the JVM at run time.) Compiler does have an fair idea but it doesn't know that for sure. So obviously, it cannot decide based on the object type. All it is left with is the variable type.

So I may have understood: in this case, the type of the variable programmer.name is decided by the compiler; anyway the compiler doesn't know which is the actual object, then it lets the variable type.

Thank you, really.

There you go

[Guillermo Ishi]

There's an easier way that doesn't depend on thinking about binding. Just remember for subclasses the variables used come from the type of the reference, and the methods used come from the type of the object.

[Roel De Nijs]

This awesome discussion can be summarized in 2 very simple (and hopefully easy to remember) but very, very, very important rules:

Which instance variables you can access is determined at compile time based on the reference variable type.

Which instance methods you can call/invoke is determined at compile time based on the reference variable type. Which instance method is actually executed is decided at runtime based on the type of the actual object (= polymorphism).

And for static/class variables and methods it's even much easier: no differences here, both are determined at compile time based on the reference variable type.

Hope it helps!
Kind regards,
Roel