aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes local final variable Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "local final variable " Watch "local final variable " New topic
Author

local final variable

gurpreet singh
Ranch Hand

Joined: Apr 07, 2006
Posts: 38
This code works fine:



but this code gives compilation error: "The final local variable y may already have been assigned".



SCJP
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14266
    
  21

"gurpreet_java" - Here on JavaRanch, we have a naming policy.

Unfortunately, your name "gurpreet_java" does not comply to the naming policy. Your display name should consist of a real-sounding first name, space, and a second name. Not only a first name, no obviously fake nickname, no initials only for the second name.

Please read the naming policy carefully and change your display name. You can change your name by editing your profile.

Please note that we are taking the naming policy seriously. If you do not change your display name, your account on JavaRanch might be locked.

This is not the first time you have been warned about this. Please change your name immediately.

Jesper Young - Bartender


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14266
    
  21

Your new name "gurpreet" is still not according to the policy.

Your display name should consist of a real-sounding first name, space, and a second name. Not only a first name.

Please read the naming policy carefully and change your name again.
PK Ghosh
Greenhorn

Joined: Aug 08, 2006
Posts: 24
See in the first example "else" make you only one choice. So Y value would have change only one.

But in the second example: compiler does only understand boolean expression inside (). As "else" is not present, compiler thinks that both of the statement of Y might execute, hence violet the rules of "final".
gurpreet singh
Ranch Hand

Joined: Apr 07, 2006
Posts: 38
takes this for an example:

CASE1


the above code works fine.
lets now interchange the if condition.


CASE2


This code generates compile time error.

can any one explains this compiler behaviour?
Kelvin Chenhao Lim
Ranch Hand

Joined: Oct 20, 2007
Posts: 513
Gurpeet, thanks for posing a very interesting question. As you probably already know, since y is an uninitialized local final variable, you are allowed to perform at most one assignment to it. Performing more than one assignment to a final local variable is a compile-time error.

Contrary to what you may expect, however, the Java compiler does not attempt to exhaustively analyze your program's control flow to determine with 100% accuracy which parts of your program are unreachable. Instead, to enforce the "at most one assignment" rule, the compiler uses a simpler rule: a final local variable must be "definitely unassigned" when it encounters an assignment to it, where "definitely unassigned" has a very precise meaning as defined in the Java Language Specification.

In CASE1, the compiler knows that the second assignment will never be reached, so there is no error. But in CASE2, the second assignment is reachable--but because there was an assignment statement before it, y is not definitely unassigned according to the precise rules defining the term. To you and me, we all know that both code fragments will only result in one assignment... but because the compiler depends on a simplified set of rules to make its judgment, it chooses to flag this as an error.

If you're interested in all the sordid details of what makes a variable "definitely unassigned" (and, conversely, "definitely assigned"), refer to this JLS page: (warning: long and confusing algorithm details inside!)

http://java.sun.com/docs/books/jls/second_edition/html/defAssign.doc.html#25979

Here's another example from the JLS page that illustrates the known limitations of the "definitely unassigned" rules:
The above code will not compile. But this code will compile:The above pair of programs are very similar to the programs in your original post.
[ November 07, 2007: Message edited by: Kelvin Lim ]

SCJP 5.0
Nabila Mohammad
Ranch Hand

Joined: Nov 05, 2007
Posts: 661



Hi.I ran this code and it is runing fine with out any errors.
Gave the output 2.
But I was wondering,Aren't you supposed to initailise local variables
(y) and that compiler will generate errors if it is not initailised.
and How come it is final.
the value can change (1 or 2) according to the condition.
so how is it final?


The future belongs to those who believe in the beauty of their dreams.Dream BIG!
Nabila Mohammad
Ranch Hand

Joined: Nov 05, 2007
Posts: 661
oops...I think i copied the wrong code!
Preeti Yarla
Ranch Hand

Joined: Sep 08, 2007
Posts: 69
Kelvin,

In CASE1 of Gurpreet Singh's second post how does the compiler know that the second case will never be reached?


According to JLS

Except for the special treatment of the conditional boolean operators &&, ||, and ? : and of boolean-valued constant expressions, the values of expressions are not taken into account in the flow analysis.


Then how does the compiler know that the second if-condition is not a possible path of execution?


SCJP
Esther Kak
Ranch Hand

Joined: Oct 11, 2006
Posts: 51
Hi,

I understand your explanation but I want to get a clear picture of a few questions that I still have. I am a novice too...

I was in an assumption that if an IF condition fails, the compiler would not execute statement or codeblock that is associated to that IF condition. IS THIS TRUE? IF NOT WHY?

In CASE2, does not the compiler know that the assignment y=1; can never be reached because first IF condition fails?
Kelvin Chenhao Lim
Ranch Hand

Joined: Oct 20, 2007
Posts: 513
First off, I must clarify that I was a bit careless in my use of the term "reached" in my earlier post. Strictly speaking, in "if (false) foo();", the foo invocation isn't considered "unreachable" per the JLS's definition, because unreachable code in the JLS sense must be flagged as a compile-time error. However, it's still "unreachable" in the broader sense because no execution path ever reaches that line. The JLS specifically acknowledges that it treats "if (false)" as a special case in order to allow so-called conditional compilation. This applies also to the general case of "if (e)" where e is a compile-time constant evaluating to false. Just FYI.

Originally posted by Preeti Vadlamudi:
Kelvin,
In CASE1 of Gurpreet Singh's second post how does the compiler know that the second case will never be reached?

I have a feeling we're going to need some help from the folks in the Java (Advanced) forum to really answer this question. I'd initially thought that I had an answer to this: when the if condition is a compile-time constant evaluating to false, the statements within the if block will not be subject to the same definite assignment flow analysis rules as statements outside. This seems supported by the fact that the compiler accepts this code:

but rejects this:
since (j>2) is not a compile-time constant in the latter.

However, your question prompted me to explore this in greater depth--and I was very surprised to discover that this code does NOT compile despite its apparent similarities to my first code fragment above:

So there's definitely more than meets the eye here. I couldn't find anything in the JLS that explains this behavior explicitly--so I suspect that this is either an implicit (and extremely subtle) derivation from the reachability & definite assignment rules... or a bug?!

As a result, I'm basically stumped at the moment. I'll look into this further when I have time, but hopefully a more knowledgeable guru can chime in with some insights. This has been an extremely interesting discussion so far, to say the least.
[ November 07, 2007: Message edited by: Kelvin Lim ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: local final variable