• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

local final variable

 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This code works fine:



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

 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"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
 
Jesper de Jong
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 513
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 664
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator



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?
 
Nabila Mohammad
Ranch Hand
Posts: 664
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
oops...I think i copied the wrong code!
 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 513
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic