Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

can you figure this out?

 
Douglas Chorpita
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's a question that may trick the profis...




Scenario:

An anonymous class is returned as a parameter. By Java rules, it is not allowed to access non-final automatic variables. However, it may access final automatic variables. Final automatic variables are not always reducable to compile-time constants. They can call methods, whose values are (naturally) only known at run time. How does Java keep track of these final automatic variables (which are not compile-time constants) when these automatic variables of the method in which the anonymous class was created no longer exist (i.e. that part of the stack is gone)?

Look at sample code:

By the time we reach line "2 - main", the automatic variables (j, wackbed and falter) of the method getIce() can NO LONGER EXIST!!! How is it possible that these automatic values can nevertheless be used in the computation of ice.getColdness() which is called in line "2 - main"?

I know the answer, but I am putting this out as a challenge to others.

How does it work?

By the way, it does work.
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is this not just about method local [anonymous] classes accessing the final variables of the method that creates them? The values are copied into the context of the method local instances.
[ July 20, 2006: Message edited by: Barry Gaunt ]
 
Douglas Chorpita
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good job, Barry.

Yes.

Java creates "hidden" instance variables in the anonymous class which are copies of the final automatic variables.

But not for all final automatics. Only for the final automatic variables which cannot be computed at compile time.
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, I thought there was something special here at first, but it's just the standard inner class stuff that candidates need to know for SCJP. I think that it's covered in K&B's and Kahlid Mughal's books.
 
Neelesh Bodas
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
w.r.t. the rule of allwing only final parameters and final automatic variables in the method-local inner class or anonymous inner class, I am not really clear regarding why only final variables are allowed (and why not non-finals too)? On reading the previous replies, I believe that the compiler could very well make arrangements of making local hidden copies of whatever variables have been accessed (irrespective of whether they are final or non-final?)
 
Henry Wong
author
Marshal
Pie
Posts: 20902
76
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On reading the previous replies, I believe that the compiler could very well make arrangements of making local hidden copies of whatever variables have been accessed (irrespective of whether they are final or non-final?)


True... But if the variables are not final, then there is an expectation that changes to the variable is possible. Since the inner class is working with a copy, this is not the case.

Henry
 
Douglas Chorpita
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Neelesh's point is interesting.

It is very convenient to make "hidden"-instance copies of automatic variables when the "method local class"-defined object is constructed.

But we can only do this for final variables, as other variables may change after the object is constructed. The copies would be out of sync with the actual value of these variables.

Theoretically non-final local variables could post their values (each time they get changed) to the objects that need their copies. This would be complicated and would create a lot of overhead.

Besides this, it still would be weird. It makes SOME sense that a final variable, even after it has gone out of scope, is perceived as having the only value it ever had. It is QUESTIONABLE that a non-final variable, after it has gone out of scope, should be perceived as having the last value it had before it went out of scope. Variables that have gone out of scope are GONE. They should probably be also perceived as GONE. Hence, the design decision to make non-final automatic variables inaccessible from method local classes seems, to me at least, to be INTELLIGENT and not just a limitation in design.
[ July 20, 2006: Message edited by: Douglas Chorpita ]
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is to be noticed that in the case of a final variable that is a reference to an instance of a class, the instance is not copied, just the reference. So the state of the referenced object can be changed by the method local instance's execution, and then the changed state is accessible to the containing method. That is, there is no cloning of the object referenced by the final reference variable.
[ July 20, 2006: Message edited by: Barry Gaunt ]
 
Douglas Chorpita
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By the way, if you really have a problem with non-final automatic variables being inaccessible, think of this. You can assign any non-final automatic variable to a final automatic variable. BAM!!! You can access the value then.

 
muthukumar koteeswaran
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Douglas Chorpita:
Here's a question that may trick the profis...




Scenario:

An anonymous class is returned as a parameter. By Java rules, it is not allowed to access non-final automatic variables. However, it may access final automatic variables. Final automatic variables are not always reducable to compile-time constants. They can call methods, whose values are (naturally) only known at run time. How does Java keep track of these final automatic variables (which are not compile-time constants) when these automatic variables of the method in which the anonymous class was created no longer exist (i.e. that part of the stack is gone)?

Look at sample code:

By the time we reach line "2 - main", the automatic variables (j, wackbed and falter) of the method getIce() can NO LONGER EXIST!!! How is it possible that these automatic values can nevertheless be used in the computation of ice.getColdness() which is called in line "2 - main"?

I know the answer, but I am putting this out as a challenge to others.

How does it work?

By the way, it does work.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic