Originally posted by Marlene Miller:
My question is why can a final variable declared in a loop be assigned to once each time around the loop? Why is that consistent with the JLS?
A variable can be declared final. A final variable may only be assigned to once. It is a compile time error if a final variable is assigned to unless it is definitely unassigned (�16) immediately prior to the assignment.
The scope of a local variable declaration in a block (�14.4.2) is the rest of the block in which the declaration appears...
Originally posted by Marlene Miller:
The scope of the variable x is a region of code within the �Statement�. After the �Statement� is executed, the �Expression� is evaluated again. At this point, the variable is out of scope.
Is that correct?
(2) Suppose we say �scope� is the textual region of the program in which a binding is active. Could a binding be not active but still exists (such as static local variables in C)?
If so, in my example, would we have to assume every time the virtual machine exits the scope of the variable, the binding is not only deactivated but also destroyed?
(I think I am wandering outside the scope of what I understand without a proper education.)
Originally posted by Marlene Miller:
It's an interesting topic, but in the real world I suppose a zealous programmer's manager would call pursuing this issue "creeping scope".
Each frame (�3.6) contains an array of variables known as its local variables. The length of the local variable array of a frame is determined at compile time...
Lets review exactly why there is such a thing as a final local variable. When inner classes were added to Java, it was realized that declaring a class inside a method creates a real problem when you want that class to make use of a local variable - either a calling parameter or a variable declared inside the method.
The storage for such a variable is in the stack frame of the Thread that calls the method and thus will be meaningless once the method exits. Since the object created from the local class could live long after the Thread exits, you have a serious potential problem.
[B]This was solved by creating a new use for "final" - the compiler handles allocating space for these local variables differently so they are not lost when the method exits.[B]
Exactly what this implies for your example with the loop is an interesting question! but for the exam you need to remember that the only local variable a local inner class can access is one labeled final.
Bill
If what is stated in bold is true, Why do I get compile error in following:
[ April 09, 2003: Message edited by: Barkat Mardhani ]
[ April 09, 2003: Message edited by: Barkat Mardhani ]
My understanding is that the variable is actually allocated on the stack frame, just like a non-final local variable -- but that, when you create an inner class referencing this variable, a copy of the variable is included as an (implicit) instance field of the inner class. This is why inner classes can use the variable even after it has gone out of scope: they carry their own private copy with them. And it is also explains why these variables must be final: otherwise, the copy could get "out of sync" with the real variable and the illusion that you are accessing a method-local variable could no longer be maintained.Originally posted by William Brogden:
[...]The storage for [a local] variable is in the stack frame of the Thread that calls the method and thus will be meaningless once the method exits. Since the object created from the local class could live long after the Thread exits, you have a serious potential problem.
This was solved by creating a new use for "final" - the compiler handles allocating space for these local variables differently so they are not lost when the method exits.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
SCJP2. Please Indent your code using UBB Code
SCJP2. Please Indent your code using UBB Code
SCJP2. Please Indent your code using UBB Code
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
It is probably not different from what you said, but it is different from what I read. No, I'm not trying to be clever hereOriginally posted by William Brogden:
So how is creating an invisible copy of the final variable that is carried by the object created by the inner class different from what I said?
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
given to the inner class in the same way that parameters are passed to methods.
SCJP2. Please Indent your code using UBB Code
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Catch Ernie! Catch the egg! And catch this tiny ad too:
New web page for Paul's Rocket Mass Heaters movies
https://coderanch.com/t/785239/web-page-Paul-Rocket-Mass
|