• Post Reply Bookmark Topic Watch Topic
  • New Topic

final keyword in java  RSS feed

 
vipul bondugula
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


the output iam getting is "Unreachable Statement".

My intention is not to get the compiler error. But i am getting compiler error. compiler checks only syntax .But in this case how it is interpreting the value...

Please provide me reason.

Thanks
Vipul Kumar.
 
Anayonkar Shivalkar
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello vipul bondugula,

The reason behind this is - final primitives are considered as compile time constants and actual values are assigned to them at compile time only.

Java 6 onwards(correct me if I'm wrong), compiler checks the actual values of such constants - e.g. while compiling do-while loop, it is 100% guaranteed that a is 10 and b is 20. It is also guaranteed that a<b will always be false, and hence compiler can safely throw unreachable code error.

I hope this helps.
 
vipul bondugula
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Anayonkar Shivalkar

Does it applicable to all kind of variables. I mean instance, class and local variables.

Thanks
Vipul Kumar.
 
Anayonkar Shivalkar
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are welcome.

Yes, it is applicable to all those variables.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anayonkar Shivalkar wrote:Java 6 onwards(correct me if I'm wrong), compiler checks the actual values of such constants - e.g. while compiling do-while loop, it is 100% guaranteed that a is 10 and b is 20. It is also guaranteed that a<b will always be false, and hence compiler can safely throw unreachable code error.

It's been like this in Java all along - nothing special about Java 6. However it doesn't apply to if statements, only loops like for and while.
 
vipul bondugula
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If your object is accessed by multiple threads, and you don't declare its fields final, then you must provide thread-safety by some other means.


By keeping volatile for the fields we can ensure thread safety . But how come with final we can ensure thread safety?

Thanks
Vipul Kumar.
 
vipul bondugula
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Mike.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
vipul bondugula wrote:By keeping volatile for the fields we can ensure thread safety . But how come with final we can ensure thread safety?

The value of a final variable cannot change, so in the case of multiple threads it cannot happen that more than one thread tries to change the variable at the same time, or that one thread is just changing the variable at the same moment another one is reading it.

Programming with immutable objects means that you don't have to use locks and synchronization, which means that making multi-threaded programs is easier and that programs will be more efficient (without locks and synchronization, threads don't have to wait for each other). Note that just making all member variables final isn't enough to make a class immutable. If you have a final variable (of a non-primitive type) that refers to a non-immutable object, then you can't change the value of the variable itself, but you can still change the content of the object that it refers to.
 
vipul bondugula
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Jesper de Jong.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
vipul bondugula wrote:
If your object is accessed by multiple threads, and you don't declare its fields final, then you must provide thread-safety by some other means.


By keeping volatile for the fields we can ensure thread safety . But how come with final we can ensure thread safety?


Neither one of those by itself automatically guarantees thread safety. They can both play a part in it, however.
 
vipul bondugula
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jeff Verdegan wrote:
Neither one of those by itself automatically guarantees thread safety. They can both play a part in it, however.


According to me , using volatile thread safety is guaranteed.

Do you have any reason that volatile in whole doesn't guarantee thread safety.
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
vipul bondugula wrote:
Jeff Verdegan wrote:
Neither one of those by itself automatically guarantees thread safety. They can both play a part in it, however.


According to me , using volatile thread safety is guaranteed.

Do you have any reason that volatile in whole doesn't guarantee thread safety.


Thread safe just means that multiple threads can operate on the code concurrently (and not break the program)... take for example, code that communicates over a network socket, do you think that it is as simple as making the Socket object volatile? The socket has state, and with multiple threads, needs to have multiple state -- and volatile can't guaranteed that it won't break.

Henry
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
vipul bondugula wrote:
Jeff Verdegan wrote:
Neither one of those by itself automatically guarantees thread safety. They can both play a part in it, however.


According to me , using volatile thread safety is guaranteed.

Do you have any reason that volatile in whole doesn't guarantee thread safety.


Simple. Any time you need to do multiple operations atomically. Declaring variables volatile won't help with that.

For a very simple example:


Here, if multiple threads call getAndIncrement(), since i++ is not atomic, there can be race conditions. You might have 8 threads reading 0, then 8 threads writing 1, so that after 8 increments the value is 1 when it should be 8. And all 8 threads can see 0 as the result of that method, when there should be one thread seeing 0, one thread seeing 1, and so on, up to one thread seeing 7.

Another example: Iterating over a Collection. Even if you do something like Collections.synhcronizedXxx(), you can declare every variable inside and outside the collection volatile, and iterating over it while another thread modifies it still will not be thread-safe.
 
Jordan D. Williams
Ranch Hand
Posts: 51
Android Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anayonkar Shivalkar wrote:It is also guaranteed that a<b will always be false, and hence compiler can safely throw unreachable code error.


I must be missing something... He declared final int a = 10, b = 20

Wouldn't while(a<b) evaluate to true?
 
Anayonkar Shivalkar
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jordan D. Williams wrote:
Anayonkar Shivalkar wrote:It is also guaranteed that a<b will always be false, and hence compiler can safely throw unreachable code error.


I must be missing something... He declared final int a = 10, b = 20

Wouldn't while(a<b) evaluate to true?

How did I do that?

Well, I actually wanted to say a<b will be true always, and compiler can understand that it is an infinite loop, and that the control will never reach to the next line (out of loop), and hence the unreachable code error.

Extremely sorry for the mistake.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anayonkar Shivalkar wrote:
Jordan D. Williams wrote:
Anayonkar Shivalkar wrote:It is also guaranteed that a<b will always be false, and hence compiler can safely throw unreachable code error.


I must be missing something... He declared final int a = 10, b = 20

Wouldn't while(a<b) evaluate to true?

How did I do that?


Could be worse. In response to Jordan's post, I replied with a whole long treatise on how "10 is less than 20" is always false. Even after editing it a few times I didn't notice my mistake. It was only this post of yours that finally snapped me out of my stupor.
 
Jordan D. Williams
Ranch Hand
Posts: 51
Android Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff,Anayonkar ... It happens to the best of us. .

Now the question is... What would have happened if the loop was while(a>b) which would evaluate to false. Since System.out.print("Hi"); will never be executed, will the compiler complain with the same error? My guess is it would right? Since the line of code will not be "reached", because the variables are final.

 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jordan D. Williams wrote:
Now the question is... What would have happened if the loop was while(a>b) which would evaluate to false. Since System.out.print("Hi"); will never be executed, will the compiler complain with the same error? My guess is it would right? Since the line of code will not be "reached", because the variables are final.


Yes, the compiler does check for reachability within the while loop -- so the example will complain that the code within the while loop is not reachable.

However, it is not because the variables are final. It is because the expression for the loop is a compile time constant (and determined to be false at compile time). The distinction is subtle, but remember, all compile time constant variables may be declared final, but not all final variables are compile time constant variables.

Henry
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:However, it is not because the variables are final. It is because the expression for the loop is a compile time constant (and determined to be false at compile time).


Although the variables being final is a necessary condition for it to be a compile-time constant.

The distinction is subtle, but remember, all compile time constant variables may must be declared final, but not all final variables are compile time constant variables.


FTFY.
 
Jordan D. Williams
Ranch Hand
Posts: 51
Android Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:
Jordan D. Williams wrote:
Now the question is... What would have happened if the loop was while(a>b) which would evaluate to false. Since System.out.print("Hi"); will never be executed, will the compiler complain with the same error? My guess is it would right? Since the line of code will not be "reached", because the variables are final.


Yes, the compiler does check for reachability within the while loop -- so the example will complain that the code within the while loop is not reachable.

However, it is not because the variables are final. It is because the expression for the loop is a compile time constant (and determined to be false at compile time). The distinction is subtle, but remember, all compile time constant variables may be declared final, but not all final variables are compile time constant variables.

Henry


OK. Now I risk going past the "Beginning Java" here, but... How can you tell the difference between variables, which use the final keyword, and are compile time constant variables and whose which are not compile time constant variables?

Thanks.
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jordan D. Williams wrote:
OK. Now I risk going past the "Beginning Java" here, but... How can you tell the difference between variables, which use the final keyword, and are compile time constant variables and whose which are not compile time constant variables?



I have written a topic about this, a few years ago....

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

Henry
 
Campbell Ritchie
Marshal
Posts: 56578
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Or you can go through the Java Language Specification contents with use ctrl-F-constant. You find about six sections, of which §15.28 might be the most useful. But it is not easy to read.
 
Jordan D. Williams
Ranch Hand
Posts: 51
Android Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Or you can go through the Java Language Specification contents with use ctrl-F-constant. You find about six sections, of which §15.28 might be the most useful. But it is not easy to read.


You were right Campbell... I tried reading that and it is way over my head. I probably should read it one day if I am really serious about Java programming though...

Henry Wong wrote:
Jordan D. Williams wrote:
OK. Now I risk going past the "Beginning Java" here, but... How can you tell the difference between variables, which use the final keyword, and are compile time constant variables and whose which are not compile time constant variables?



I have written a topic about this, a few years ago....

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

Henry


Why couldn't they write it like that in the JLS?! ... Thanks so much for writing that article and linking to it here. It is very clear.
 
Campbell Ritchie
Marshal
Posts: 56578
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You were given two options and one worked. Shame my suggestion was the one that didn’t. But I did say not easy to read.

Yes, you will have to read the JLS some time, but it is not generally intended for beginners.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jordan D. Williams wrote:Why couldn't they write it like that in the JLS?! ...

Because it's written by geeks (I would have preferred the 'tw' word, but I'll get banned (or demoted)) who have no conception of the breadth and nuance of the language of Shakespeare. I hope Henry will excuse me when I say that I find it particularly ironic that such a fine distillation of the subject is written by someone with the surname Wong (I gave it a gold star, BTW).

Winston
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!