• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

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

 
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Stack or heap does not matter on this.

final variables may be read, not set or changed.
 
Fu Dong Jia
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 131
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i is not a instance variable!
 
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
>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
Posts: 124
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Nicholas Jordan
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
I've never won anything before. Not even a tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic