[1492] in java-interest

home help back first fref pref prev next nref lref last post

Re: Local variables can't be final?

daemon@ATHENA.MIT.EDU (John D. Mitchell)
Wed Sep 6 03:09:41 1995

Date: Tue, 5 Sep 1995 20:24:38 -0700
From: "John D. Mitchell" <johnm@emf2-003.emf.net>
To: edanuff@protagonist.com (Ed Anuff)
Cc: "John D. Mitchell" <johnm@emf2-003.emf.net>, java-interest@java.sun.com
In-Reply-To: <v02110100ac72c5b99f3c@[204.156.137.145]>

Ed Anuff writes:
[...]
> >>     |- 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?

Ah.  Me thinks it's an oversight that is was allowed to be changed.
Certainly it seems to make perfect sense to allow 'final' local variables
from a scoping perspective at minimum.

[...]
> >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.

Aha, that seems like useful and consistent semantics.


[...]
> 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.

Hmm...  This seems inconsistent with the use of 'final' when applied to
methods (i.e., a 'final' method cannot be overridden).  Seems like a nice,
easy inconsistency to fix.

Thus, on variables, 'static' means once per class (but overridable),
'final' means unchangeable/constant (but overridable), and 'static final'
means an unchangeable/constant that is not overridable.

That would also clean up that same hole but where the variables/constant
was defined in an Interface rather than a Class.  Can't allow have some
some grunge hacker to change the value of a constant provided in an
Interface for e.g., security reasons at the very least.

Take care,
	John
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com

home help back first fref pref prev next nref lref last post