[1491] in java-interest
Re: Local variables can't be final?
daemon@ATHENA.MIT.EDU (Ed Anuff)
Wed Sep 6 02:46:31 1995
Date: Tue, 5 Sep 1995 20:08:24 -0800
To: "John D. Mitchell" <johnm@emf2-003.emf.net>, java-interest@java.sun.com
From: edanuff@protagonist.com (Ed Anuff)
>This is a bit unclear from the Alpha v0.3 draft of Sun's "Java Language
>Specification". There's no direct mention of 'local variables' except for
>the distinguishment that they are given in a parenthetical remark in
>section 4.2.1 talking about instance variables. It seems clear though from
>the general basis of starting from the C language that this should be
>allowed. Also, from the pseudo-grammar given in Appendix A that the
>intention is to allow for this (i.e., 'Statement' is made up of, among
>other things, 'VariableDeclaration' which, in turn, allows for the
>'Modifiers' preceding the variables).
Exactly.
>> |- The compiler doesn't complain about the following code:
>[...Local modification of 'final' local variable...]
>
>Seems to be a bug.
The question is whether its a bug that a final local variable was allowed,
or that the variable was able to be changed?
>[...]
>> I've try your code and look at the doc "java language specification". So
>> It seem to me that a final variable must be a constant !
>
>The specification says that directly on page 18, section 4.10.3 of Sun's
>Java Language Specification: "Variables marked as *final* behave like
>constants".
>
>
>> When you declare a final variable there is an only memory emplacement
>> which is shared by all the instantiations of this class (see "Java
>> language environnement" page 26 Part "Static and Final ...").
>
>Hmm... You seem to be confusing the notion of 'static', 'final' and 'static
>final'. When referring to 'variables': 'static' means that the variable
>is (in Smalltalkian terms :-) a 'class variable' (i.e., there is only one
>actual instance of that variable per *class*); 'final' means that the
>variable is an unchanging/constant; and 'static final' means that there is
>only a single instance of the variable for the class and it is
>unchanging/constant.
>
>In that light, it seems silly to me to ever have a 'final' variable that
>is not also 'static'. Does that mean that 'final' all by itself should
>imply 'static'? It's sort of an odd thing since there isn't (in conceptual
>terms anyways) any actual storage for 'constants'. The translator is
>allowed to inline constants or not as it chooses (so in this light, it
>seems silly to ever have to say 'static final' at all). Hmm... :-)
My orignal belief was that 'static final' was useful because a variable of
the same name can be declared in a subclass, effectively "overriding" the
superclass's variable declaration. The final modifier would ostensibly
prevents this, in addition to making the variable a constant. The need for
final and static is shown in the following example (BTW, these examples all
compile without warning or error):
class var_a {
static int a = 5;
}
class var_b extends var_a {
static int a = 10;
}
So you would think that if variable a was declared final static in class
var_a, that the compiler would complain when trying to compile class var_b.
For example, you would expect the following to not work:
class var_a {
final static int a = 5;
}
class var_b extends var_a {
final static int a = 10;
}
But, naturally, it does work. Of course, this is tangental to my original
post about final local variables, but since John brought it up, I thought
I'd point it out.
Ed
Ed Anuff
edanuff@protagonist.com
http://www.protagonist.com/
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
