aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Is final variable i:final int i=0;on stack or heap? 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 "Is final variable i:final int i=0;on stack or heap?" Watch "Is final variable i:final int i=0;on stack or heap?" New topic
Author

Is final variable i:final int i=0;on stack or heap?

Fu Dong Jia
Ranch Hand

Joined: May 23, 2007
Posts: 131
Hi all!
Is final variable i on stack or heap?
why Method-Local Inner Classes can access the method's final variable,but normal variable?


who dare win!<br />SCJP5(94%)|SCWCD5(86%)|SCBCD(100%)|SCEA in progress
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
Stack or heap does not matter on this.

final variables may be read, not set or changed.


"The differential equations that describe dynamic interactions of power generators are similar to that of the gravitational interplay among celestial bodies, which is chaotic in nature."
Fu Dong Jia
Ranch Hand

Joined: May 23, 2007
Posts: 131
hi
Because of Method-Local Inner Classes is on heap,
so it's wifecycle is longer than normal variable in the method.
So Method-Local Inner Classes can not access normal variable,
but can access final variable.
So i want to know,if final variable is on the heap,or has a longer lifecycle than normal variables.
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
I cannot see where final should make any difference. Try Foo.this.i

I thought inner class had access to immediate outer class variables.
Fu Dong Jia
Ranch Hand

Joined: May 23, 2007
Posts: 131
i is not a instance variable!
nico dotti
Ranch Hand

Joined: Oct 09, 2007
Posts: 124
>I thought inner class had access to immediate outer class variables.
Method level inner classes can access class variables, but he's talking about accessing variables that are local to the method it's in. So as his demonstration shows, the method local inner class can't access the non-final variable.

I'm pretty darn sure that the final local variable is still just a stack variable as otherwise that would break the axiom that all method level vars live on the stack. However, from digging a little, it seems that the method level inner class actually makes a copy of the local variable as a hidden field (because the method may complete and the local stack variables may be destroyed while the local inner class is still referenced!) So if it makes a copy of the local variable, the final will insure that the values of the local version of the variable, and the copied inner local class's version aren't different (think about it...otherwise they could run off in separate directions with all sorts of differing values!), which could get quite confusing. So yeah, the final local variable lives on the stack and gets blown away like regular local vars. But the final insures that it's value won't differ from the method local classes version.

Here are some sites I found that seem to speak to this though I can't vouch for their accuracy and they only allude to how it really works. I'm sure Bert or one of the ranch-hands knows exactly how this gets implements...nevertheless check these out:

http://renaud.waldura.com/doc/java/final-keyword.shtml

http://mindprod.com/jgloss/nestedclasses.html
nico dotti
Ranch Hand

Joined: Oct 09, 2007
Posts: 124
BTW, the first link says something (this is off this thread's topic):
"Private and static methods are always implicitely final, since they cannot be overridden." This is true but slightly misleading because a final method will generate a compiler error while a private method that 'appears' to be overriden (it's actually shaddowed) does not. Just a wrinkle I noticed. However, both links basically mention that local final vars are copied by a local method inner class into a hidden field for the inner class and thus for consistency reasons, the local var is marked final...hope this is helpful and sorry for my little tangent above
Jan van Mansum
Ranch Hand

Joined: Oct 19, 2007
Posts: 74
This was something I never completely understood myself. So the answer is: both, there is a copy on the stack and a copy on the heap (as field of the method local object).

Interesting links Nico Dotti. Thanks


SCJP 1.4, SCWCD 1.4
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
local stack variables may be destroyed while the local inner class is still referenced!)

How ? If class LivingstonCarpetBagger goes out of scope, becuse method return quickly, how did anyone get a reference to method-local-class MailCheck ?

And if scoping of methods (and possibly inner-classes) requires in i or j to be final, then they are no longer variables and this whole notion of compiler semantics enforcing copy semantics never set really well with me. If you want a copy, get a copy. If you want a final, say so. But where in Captain Bluetooth do they make an innner classes copy of somevar final if the original var was never final and the coder did not ask for no-write-back to be applied silently ? Original poster's code is out of scope right now because the script is loaded but I notice the sample code steps the access through not-just-one curly braces level and is probably at issue in the // compile-error comment.

Poster's title is: final variable i:final int i=0;on stack or heap?
, then in provided snippet i is mutable, j constant - none of which has anything to do with Because of Method-Local Inner Classes is on heap,so it's wifecycle is longer than normal variable in the method.

{btw Fudong, it's lifecycle and more correctly that word should be scope or scoping - scope is how far away something matters.}

(think about it...otherwise they could run off in separate directions with all sorts of differing values!),

That's why they are called variables. If you want every section of codebase working on the same whatchamacallit you are going to get some global warming from the Shining Sun of Code Correctness in Objected Orientation.

But the final insures that it's value won't differ from the method local classes version.

Well ask the original poster if this is what is concern of merit in momentary post, the post title is not of concern or at issue in OO.

I'm sure Bert or one of the ranch-hands knows exactly how this gets implements

Yeah, I know, they are always watching and if one of them hammers us let them hammer me becuase I can take the heat. It looks like we are going to need some to get across to original poster that stack or heap not at issue in sample code provided. Any addressable space is addressable space, iow all program variable ram can 'see' all program variable ram.
[ December 03, 2007: Message edited by: Nicholas Jordan ]
 
 
subject: Is final variable i:final int i=0;on stack or heap?