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.
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".
Joined: Apr 07, 2006
takes this for an example:
the above code works fine. lets now interchange the if condition.
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!)
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 ]
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!
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?
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
Joined: Oct 20, 2007
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 ]