wood burning stoves 2.0*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes can you figure this out? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "can you figure this out?" Watch "can you figure this out?" New topic
Author

can you figure this out?

Douglas Chorpita
Ranch Hand

Joined: May 09, 2006
Posts: 97
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.


SCJP 1.4 - 95%
Barry Gaunt
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
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 ]

Ask a Meaningful Question and HowToAskQuestionsOnJavaRanch
Getting someone to think and try something out is much more useful than just telling them the answer.
Douglas Chorpita
Ranch Hand

Joined: May 09, 2006
Posts: 97
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

Joined: Aug 03, 2002
Posts: 7729
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

Joined: Jul 20, 2006
Posts: 107
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
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

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


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

Joined: May 09, 2006
Posts: 97
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

Joined: Aug 03, 2002
Posts: 7729
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

Joined: May 09, 2006
Posts: 97
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

Joined: Jul 21, 2006
Posts: 1
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: can you figure this out?