Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Compile time constant

 
Ravi Khadgi
Greenhorn
Posts: 20
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


While I try to compile the code, the compiler complains that a is not a compile time constant.
However if I use int in place of Integer in line 3, there is no compilation error.
I would like to know why the expression final Integer a=10; is not a compile time constant.
 
Boris Mechkov
Ranch Hand
Posts: 72
Java Netbeans IDE Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ravi Khadgi wrote:
While I try to compile the code, the compiler complains that a is not a compile time constant.
However if I use int in place of Integer in line 3, there is no compilation error.
I would like to know why the expression final Integer a=10; is not a compile time constant.


"final Integer in" means that the reference 'in' is final - you cant point err...refer to a different object. But the Integer object itself CAN change.
int is primitive and has to be final in order for the code above to compile.
 
Ikpefua Jacob-Obinyan
Ranch Hand
Posts: 394
Eclipse IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Guys, in other to consolidate what Boris already said, I want to remind you just incase you already know that there are NO final objects in java. This simply means that the 'state' of the 'Integer in object (10)' can NEVER be constant. And we know that the arguments for Case statements MUST be constants.
 
Matthew Brown
Bartender
Posts: 4567
8
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just to confuse things further...Integer is an immutable class. So the state is fixed. But the compiler doesn't go to the bother of trying to work that out - it won't treat a reference as a compile-time constant in this way.
 
Ravi Khadgi
Greenhorn
Posts: 20
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Matthew, I was also thinking the same. Once we assign a value 10 to an integer using final Integer a=10;, there is no way we can change the value. And it doesn't allow to refer to another Integer object as we have used the keyword final while declaring it. So, it should have been treated as a constant. But as you mentioned that the compiler doesn't bother to check it that way, I am convinced. Thanks everyone for the explanation.
 
Ikpefua Jacob-Obinyan
Ranch Hand
Posts: 394
Eclipse IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Matthew Brown wrote:Just to confuse things further...Integer is an immutable class. So the state is fixed. But the compiler doesn't go to the bother of trying to work that out - it won't treat a reference as a compile-time constant in this way.


Matthew I am partialy in dis-agreement here when you say the 'state' is fixed. Is that contradicting what I said about the 'state' of the 'Integer in' object (10)? lets modify Ravi's code and see what happens:



Output:
11
2

This confirms what I said, I beleive that I am the one misunderstanding what you said, could you please explain futher?.
Thanks.



 
Boris Mechkov
Ranch Hand
Posts: 72
Java Netbeans IDE Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ikpefua Jacob-Obinyan wrote:
Matthew Brown wrote:Just to confuse things further...Integer is an immutable class. So the state is fixed. But the compiler doesn't go to the bother of trying to work that out - it won't treat a reference as a compile-time constant in this way.


Matthew I am partialy in dis-agreement here when you say the 'state' is fixed. Is that contradicting what I said about the 'state' of the 'Integer in' object (10)? lets modify Ravi's code and see what happens:



Output:
11
2

This confirms what I said, I beleive that I am the one misunderstanding what you said, could you please explain futher?.
Thanks.




It is indeed immutable, once the value is 10 you can't change it. In the above code if you try to print the value of "a" it will be 10, rather than 11. One would think that changing the state of an object via two different references (pointing towards the same object), would take effect here since there are no final objects, but this above code does not change the Integer a object (10)....
 
Ikpefua Jacob-Obinyan
Ranch Hand
Posts: 394
Eclipse IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Independently of what you guys say, be rest ASSURED that there are NO final objects in java. Please check this link

http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html

Checkout section 4.5.4 final Variables.

Ravi Khadgi Matthew, I was also thinking the same. Once we assign a value 10 to an integer using final Integer a=10;, there is no way we can change the value.


Ravi I guess after reading the above you will have a second thought.
 
Boris Mechkov
Ranch Hand
Posts: 72
Java Netbeans IDE Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ikpefua Jacob-Obinyan wrote:Independently of what you guys say, be rest ASSURED that there are NO final objects in java. Please check this link

http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html

Checkout section 4.5.4 final Variables.

Ravi Khadgi Matthew, I was also thinking the same. Once we assign a value 10 to an integer using final Integer a=10;, there is no way we can change the value.


Ravi I guess after reading the above you will have a second thought.


This is partially true. But there are objects that are immutable like String for example. Once initialized, that value of a String cant change. But i also think that we are getting off on a tangent here...
 
jishnu dasgupta
Ranch Hand
Posts: 103
Eclipse IDE Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ikpefua Jacob-Obinyan wrote:[Matthew I am partialy in dis-agreement here when you say the 'state' is fixed. Is that contradicting what I said about the 'state' of the 'Integer in' object (10)? lets modify Ravi's code and see what happens:



Output:
11
2

This confirms what I said, I beleive that I am the one misunderstanding what you said, could you please explain futher?.
Thanks.





Hi Jacob,

I think if you print the value of a2 after printing the value of ++a2, all your doubts will be resolved.
 
Ravi Khadgi
Greenhorn
Posts: 20
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ikpefua Jacob-Obinyan wrote:Independently of what you guys say, be rest ASSURED that there are NO final objects in java. Please check this link

http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html

Checkout section 4.5.4 final Variables.

Ravi Khadgi Matthew, I was also thinking the same. Once we assign a value 10 to an integer using final Integer a=10;, there is no way we can change the value.


Ravi I guess after reading the above you will have a second thought.


Ikpefua, I understand that there is NO final objects in java. My concern here is neither you can change the state of the object nor you can refer to some other object. Hence, for me final Integer a=10; is a constant. However the compiler doesn't bother to look into it that way.
 
Ikpefua Jacob-Obinyan
Ranch Hand
Posts: 394
Eclipse IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ravi wrote: Hence, for me final Integer a=10; is a constant. However the compiler doesn't bother to look into it that way.


Hello Ravi, I agree with you, the above statement as-it-stands is correct the compiler does not bother to even look at it that way that is why it says that it is NOT a compile time constant.
 
Vlado Zajac
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By definition compile-time constant expression can be only String or primitive type.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic