This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Binding of variables and methods at compile time and runtime

 
pagano monello
Ranch Hand
Posts: 38
1
Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:



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
Enthuware Software Support
Ranch Hand
Posts: 3819
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 467
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

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
Ranch Hand
Posts: 38
1
Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Marshal
Pie
Posts: 22118
88
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 467
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Enthuware Software Support
Ranch Hand
Posts: 3819
10
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 38
1
Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 38
1
Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 38
1
Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Enthuware Software Support
Ranch Hand
Posts: 3819
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 789
C++ Linux Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic