aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes misunderstanding in K&B book Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "misunderstanding in K&B book" Watch "misunderstanding in K&B book" New topic
Author

misunderstanding in K&B book

Lucas Smith
Ranch Hand

Joined: Apr 20, 2009
Posts: 804
    
    1

There is the sentence in K&B book on the page of 55:
"The keyword this always, always, always refers to the object currently running".

So what about that:


The output: 0


SCJP6, SCWCD5, OCE:EJBD6.
BLOG: http://leakfromjavaheap.blogspot.com
Sebastian Janisch
Ranch Hand

Joined: Feb 23, 2009
Posts: 1183
It's because instance variables do not take part in polymorphism.

You create an instance of Cast, which calls the get method implemented in Tree which then uses it's copy of the x var.

If you override get in Cast and output x, it will return 10.


JDBCSupport - An easy to use, light-weight JDBC framework -
Lucas Smith
Ranch Hand

Joined: Apr 20, 2009
Posts: 804
    
    1

So "this" not always apply to currently executing object.
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

You're confusing yourself by using the variable x in two places. Change the names of the two variables and it will make more sense.

Using a more defined method name, rather than a generic get might make it easier to follow as well.

Variables don't get overridden, they get 'shadowed.' It's the shadowing that is causing confusion.

Look at the following code. From Java's point of view, there is no difference. Why would you expect the getZero method in this code to return anything other than 0? (Assuming it compiles. I didn't compile it.)




-Cameron McKenzie
Lucas Smith
Ranch Hand

Joined: Apr 20, 2009
Posts: 804
    
    1

Cameron Wallace McKenzie wrote:
Variables don't get overridden, they get 'shadowed.' It's the shadowing that is causing confusion.

In this case the variable is hidden, not shadowed.
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

See!!! It's even confusing me!

Two variables that are part of the same class with the same variable name is confusing, regardless of which label gets affixed to it.

-Cameron McKenzie
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14350
    
  22

So, you have a class Cast which extends class Tree. Now in line 6 you create a new Cast object, and in line 7 you call the get() method on that object. In line 13 you access the variable x of the object via the 'this' reference.

Note that there is only one object - the object to which 'c' refers. The 'this' reference in line 13 refers to the same object that 'c' refers to in lines 6 and 7.

Don't confuse 'object' and 'class'.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Lucas Smith
Ranch Hand

Joined: Apr 20, 2009
Posts: 804
    
    1

Cameron Wallace McKenzie wrote:See!!! It's even confusing me!

Two variables that are part of the same class with the same variable name is confusing, regardless of which label gets affixed to it.

-Cameron McKenzie

But the confusing situations are the spirit of the exam
Lucas Smith
Ranch Hand

Joined: Apr 20, 2009
Posts: 804
    
    1

Jesper Young wrote:The 'this' reference in line 13 refers to the same object that 'c' refers to in lines 6 and 7.

So why does it print 0 instead of 10? The visible x is that contains the value of 10. The x from tree is hidden.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18996
    
  40

Lukas Smith wrote:
Jesper Young wrote:The 'this' reference in line 13 refers to the same object that 'c' refers to in lines 6 and 7.

So why does it print 0 instead of 10? The visible x is that contains the value of 10. The x from tree is hidden.


Hidden doesn't mean that it is not accessible -- as you have seen with this example. Your get() method uses the "hidden" x variable -- as the first responder to this topic mentioned, "instance variables do not take part in polymorphism".

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Lucas Smith
Ranch Hand

Joined: Apr 20, 2009
Posts: 804
    
    1

So there should be:
"The keyword "this" always, always, always refers to the object currently running when polymorphism works."
Am I wrong?
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18996
    
  40

Lukas Smith wrote:So there should be:
"The keyword "this" always, always, always refers to the object currently running when polymorphism works."
Am I wrong?


The "this" variable does refer to the object whose instance method is being called. This fact doesn't change just because you disagree with how Java implements polymorphism.

If you don't believe this, simply store a copy of the Cast variable somewhere. Then if you modify the get() variable to access the variable, you'll see that it is the same instance.

Henry
Ninad Kulkarni
Ranch Hand

Joined: Aug 31, 2007
Posts: 802



Here the nearest scope of x is tree class not cast class. Java choose always nearest scope.
Correct me if I am wrong.


SCJP 5.0 - JavaRanch FAQ - Java Beginners FAQ - SCJP FAQ - SCJP Mock Tests - Tutorial - JavaSE7 - JavaEE6 -Generics FAQ - JLS - JVM Spec - Java FAQs - Smart Questions
Lucas Smith
Ranch Hand

Joined: Apr 20, 2009
Posts: 804
    
    1

Ninad Kulkarni wrote:

Here the nearest scope of x is tree class not cast class. Java choose always nearest scope.
Correct me if I am wrong.


Here the nearest scope of x is tree class not cast class. Java choose always nearest scope. - that would explain everything
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18996
    
  40

Ninad Kulkarni wrote:
Here the nearest scope of x is tree class not cast class. Java choose always nearest scope.
Correct me if I am wrong.


This is not a case of two variables being in scope, and java choosing the one that is "nearest scope" (quotes because it is not an official term).

The x variable (of the cast class) is *not* in scope to the get() method. Period. To prove this, you can move the other x variable "really far away", and you will see, that it will not access the x variable in the cast class.



Henry
Ninad Kulkarni
Ranch Hand

Joined: Aug 31, 2007
Posts: 802

The x variable (of the cast class) is *not* in scope to the get() method.


You are absolutely correct Henry.
Thanks for such a nice explaination. Now I will refer it as "The x variable (of the cast class) is *not* in scope to the get() method"
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: misunderstanding in K&B book