aspose file tools*
The moose likes Beginning Java and the fly likes Final variables Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Final variables" Watch "Final variables" New topic
Author

Final variables

chulani weerathunga
Greenhorn

Joined: Oct 29, 2012
Posts: 3


can someone please explain this programme...this gets a compile error....

if we put final int x=101 to the same programme there won't be any compile errors...
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

If the "if" condition is false, the body of the "if" will not be entered, and y's value will be undefined. We can't use a local variable until we've assigned a value to it.

The reason that you get the error in one case and not another is that this is a compile-time constant:


but this is not:


and when we have in the case of a compile-time constant (the first case), the compiler effectively turns that into , which is of course equivalent to , which the compiler in turn treats as if there were no "if" at all, and the compiler knows that y will always have a value assigned to it. In the non-constant case, the compiler doesn't know that the "if" will always be true, so it can't be sure that y will have a value assigned to it before we try to read from it.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 13870
    
  10

Somebody asked the same question (with the same code as your example!) last week.

And somebody else asked the same question too!


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
chulani weerathunga
Greenhorn

Joined: Oct 29, 2012
Posts: 3
I got all these..but still i didnt get why we have to assign the values toa final variable on the same step that we declare that variable and not in another line.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18108
    
  39

chulani weerathunga wrote:I got all these..but still i didnt get why we have to assign the values toa final variable on the same step that we declare that variable and not in another line.


Answers from two of the duplicate topics (in addition to the explaination by Jeff here) ...

Henry Wong wrote:
Dinuka Nadeeshan wrote:Thankx everyone very much for reply me, I got some mistake in declaration.
However I haven't any idea yet about this.:-/ Can someone give answer in detail, with compiler's act for this



Go back and reread the answer from the other topic...

http://www.coderanch.com/t/596232/java/java/Why-there-compiler-error

And when you are done with that, then this topic may also help...

http://www.coderanch.com/t/454384/java/java/compile-time-constant


Henry Wong wrote:
Ranjith Suranga wrote:
There is a error now, why is this happened ? Why compiler doesn't reorganize the final variable value when we initialize it later....?



BTW, the other two topics do answer this question, but to save time. The compile error is not directly related to final variables -- it is related to compile time constant variables, and that is related to final variables. See this link for more details.

http://www.coderanch.com/t/454384/java/java/compile-time-constant

So, basically, in one case, it is a compile time constant. In the other, it is not a compile time constant.


You need to understand what is a compile time constant -- not sure how I can explain it differently.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7045
    
  16

chulani weerathunga wrote:I got all these..but still i didnt get why we have to assign the values toa final variable on the same step that we declare that variable and not in another line.

You don't. You can also assign values to final fields in a constructor. The main thing is that you can only assign to them ONCE.

Your example is specifically a final local variable, and those must be instantiated at declaration time otherwise they will either:
(a) be assigned a default value (for primitives), or
(b) be unassigned.
And the latter usually leads to compiler errors.

My question is: why would you NOT want to assign a value?

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Artlicles by Winston can be found here
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

chulani weerathunga wrote:I got all these..but still i didnt get why we have to assign the values toa final variable on the same step that we declare that variable and not in another line.


Because the language definition says that if you don't assign at the point you declare it, it's not a constant.
chulani weerathunga
Greenhorn

Joined: Oct 29, 2012
Posts: 3
Thanks for everyone....
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2969
    
    9
Winston Gutkowski wrote:
chulani weerathunga wrote:I got all these..but still i didnt get why we have to assign the values toa final variable on the same step that we declare that variable and not in another line.

You don't. You can also assign values to final fields in a constructor. The main thing is that you can only assign to them ONCE.

Your example is specifically a final local variable, and those must be instantiated at declaration time otherwise they will either:
(a) be assigned a default value (for primitives), or
(b) be unassigned.
And the latter usually leads to compiler errors.

No, that is... misleading, at best. Jeff's answer addresses why the variable must be final in order to allow the other code involving variable y to compile. The variable y is only considered by the compiler to be definitely assigned if x is a constant. That's why x has to be a constant, to allow the code with y to compile.

However, Winston appears to be ignoring the situation with y and talking about final vars in general - and in this context, the comments above are not correct. A final local variable does not have to be "instantiated" at declaration time. It also does not have to be assigned a value. It does need to be definitely assigned before it is used - but this can be several lines later, if necessary. Under no circumstances will a local variable get a default value, primitive or not. A non-final instance or class field could get a default value (0, false, or null), but not a local variable.

Winston Gutkowski wrote:My question is: why would you NOT want to assign a value?

For me, it sometimes happens that I need to choose between several values - so I do something like this:

Often people achieve this sort of thing by leaving out the final, and assigning an initial value to x, such as null. But I see no reason to do that, as (a) I do not intend null to ever be the value of x, so why make such an assignment? And putting in the final there communicates that I only intend x to be assigned once, and if someone later screws up the conditions such as to accidentally assign it twice, it will show as an error. I can also trust that the compiler will guard against the possibility that I might forget the final "else" and leave x unassigned. If there is any chance of x being unassigned, the compiler will let us know. That's as it should be. If the compiler doesn't complain, I know that all possible branches of the if/else/if are covered, and the x is definitely assigned.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Mike Simmons wrote:A non-final instance or class field could get a default value (0, false, or null)


Not "could." "Does." And it gets a default value whether it's final or not.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2969
    
    9
Jeff Verdegan wrote:
Mike Simmons wrote:A non-final instance or class field could get a default value (0, false, or null)


Not "could." "Does." And it gets a default value whether it's final or not.

A non-final instance or class field could get a default value, if it's not explicitly assigned another value when it's declared. And if the variable is final, you will usually get a compilation error, not a default value. There is a loophole to get a default value for a final class field (not an instance field), before it's assigned to something else, but that's obscure - I intentionally did not say what the situation was for a final field, because I thought that loophole was too obscure for beginning Java. I think if you try to come up with a code example, you'll find it's pretty difficult to see a default value for a final field.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2969
    
    9
OK, on double-checking, fields do get a default value, period. But I'm talking about the value that people actually see, which is the value set by an initializer or other definite assignment, before the field is used. Default values can be observed under special circumstances, but again, it's obscure for Beginner, no?
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Mike Simmons wrote:
Jeff Verdegan wrote:
Mike Simmons wrote:A non-final instance or class field could get a default value (0, false, or null)


Not "could." "Does." And it gets a default value whether it's final or not.

A non-final instance or class field could get a default value, if it's not explicitly assigned another value when it's declared.


No, it always gets assigned a default, whether it's final or not. JLS v3, 15.9.4 Run-time Evaluation of Class Instance Creation Expressions says:
The new object contains new instances of all the fields declared in the specified class type and all its superclasses. As each new field instance is created, it is initialized to its default value (ยง4.12.5).


There are no qualifications there about "could," or about final vs. non-final. I suppose it's possible that may have changed in Java 7. I haven't looked at that version of the JLS yet.

And if the variable is final, you will usually get a compilation error, not a default value.


Are you talking about reading a default value from these variables? When you said, "A non-final instance or class field could get a default value," I took it to mean that those fields could "receive" those values--i.e., have those values assigned to them. If you're talking about reading those values from a field before the variable is initialized by our code, then, yes, I think you're correct that it can't be done on a final field.

My apologies for any misunderstanding, if that's the case.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7045
    
  16

Jeff Verdegan wrote:My apologies for any misunderstanding, if that's the case.

Actually, it sounds as if it was my fault.

And @Mike: you're quite right. I should have looked a bit closer at what the problem really was.

Winston
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2969
    
    9
Jeff: looks like we were posting about the same time - i assume you've now read my last post, and yes, that's what I meant. "Get" a value in the sense of "end up with by the time any normal code can read it", regardless of being temporarily assigned a default value at declaration. I was less than clear in my terminology there; sorry about that.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Final variables
 
Similar Threads
Compile time constant
Why there is a compiler error?
Final variables initializing
Initializing variables
final variables