Originally posted by Ross Goldberg:
But what doesn't make sense is how final variables of a method are any different....don't they also live on the stack and get blown away when the method goes out of scope?
Originally posted by Ross Goldberg:
...The weird thing about the above scenario is that the variable doesn't exist (presumably) until the method is entered, even though it is final. After all, why should it create something not related to the object's state if that method might never be called...let alone keep it around? After all, when the method is done, so is that variable, regardless of whether or not it is final---or so I would think. But you are indicating that the final variable, though tied to a method instance (even if the value doesn't change), is going to stick around regardless. Just doesn't seem to fit the rules...does it?
Ross
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
"I'm not back." - Bill Harding, Twister
I had thought that my response was clearly a bit tounge in cheek. But there is a lie here. The lie is that the method variables "have" to be final. The only reason they "have" to be final is because Sun thought it would be too confusing if they weren't final. That is where my complaint is.Originally posted by Jim Yingst:
So I'm not sure where this "myth about the stack" idea comes from, Tom. Was there a specific Sun source you read that promulgated it?
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Originally posted by Jim Yingst:
[Thomas]:
[b][Alton]: I believe final variables lives in the constant pool, not in the stack.
Incorrect. You're thinking of compile-time constants. A variable can be final without being a compile-time constant; if so, it gets created on the stack. Though it's possible some optimizations might be made, depending how/if the variable is used - but by default, it's probably still on the stack.
[ July 27, 2003: Message edited by: Jim Yingst ]
Ron Newman - SCJP 1.2 (100%, 7 August 2002)
"I'm not back." - Bill Harding, Twister
If users want a nonfinal variable, they can explicitly make a copy, then change one to their hearts' content.
Ron Newman - SCJP 1.2 (100%, 7 August 2002)
Originally posted by Barkat Mardhani:
This can inherit from both mother and father genes. The class ApplicableGenes can hold the universal truth that what genes supercedes what under what condition.
Someone will have to make a good argument for need for inner classes.
Thanks
Barkat
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
"I'm not back." - Bill Harding, Twister
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
the way it was implemented was yucky -- they had to store the value of the non-final local variable into some place in the heap.
Ron Newman - SCJP 1.2 (100%, 7 August 2002)
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Originally posted by Kathy Sierra:
BUT... according to Sun folks, just about everyone (if not everyone) implements it the simplest way, by making a behind-the-scenes 'secret' member variable in the inner class object which holds the value of the final variable. In other words, the value of the final local variable is assigned to a member variable of the inner class object, without your having to explicitly do that yourself.
"I'm not back." - Bill Harding, Twister
Ron Newman - SCJP 1.2 (100%, 7 August 2002)
Originally posted by Jim Yingst:
The code you showed uses compile-time constants only. Try these:
final Integer one = new Integer(1);
final String s = args[0];
final int[] ints = new int[10];
final double rootTwo = Math.sqrt(2);
Ron Newman - SCJP 1.2 (100%, 7 August 2002)
Originally posted by Ron Newman:
To see what Jim's talking about, you need to declare those final local variables inside the method m(), not in the class Sample6a .
SCJP2. Please Indent your code using UBB Code
"because of potential synchronization problems, there is by design no way for two objects to share access to a changeable local variable."
"I'm not back." - Bill Harding, Twister
"I'm not back." - Bill Harding, Twister
The only restriction is that a local variable or method parameter can be accessed only if it is declared final. The reason for this restriction relates mainly to multithreading issues and ensures that all such variables have well-defined values when accessed from the inner class.
Originally posted by Jose Botella:
Alton the compiler will pass them to the contructor of the inner class, and they will be stored as fileds of the instance of the inner class.
[/CODE]
Why should I lose weight? They make bigger overalls. And they sure don't make overalls for tiny ads:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|