Every case constant expression associated with a switch statement must be assignable (�5.2) to the type of the switch Expression.
If you look at the link from the JLS then year of type Integer is assignable to bootNumber AND year.intValue (which is a constant expression) is assignable to bootNumber, as year is defined as final this is a constant expression.
What did I not consider, or what is my beatiful compiler considering which I'm overlooking? [ January 05, 2006: Message edited by: Thomas De Vos ]
Try your free <a href="http://www.javacertificate.com" target="_blank" rel="nofollow">SCJP 1.4</a> certification centre.<br />Try your free <a href="http://www.j2eecertificate.com" target="_blank" rel="nofollow">SCWCD</a> certification centre.<br />Try your free <a href="http://www.ejbcertificate.com" target="_blank" rel="nofollow">SCBCD</a> certification centre.<br />Try your <a href="http://www.webspherecertificate.com" target="_blank" rel="nofollow">Websphere (Test 285) </a> certification centre.<br />Try your <a href="http://www.j2mecertificate.com" target="_blank" rel="nofollow">SCMAD</a> certification centre. (New)<br /> <br /><a href="http://blogs.javacertificate.com" target="_blank" rel="nofollow">Java/J2EE Certification Blogging</a>
Joyce [ January 05, 2006: Message edited by: Joyce Lee ]
Thomas De Vos
Joined: Apr 12, 2003
That makes perfect sense. Thanks.
Thanks, the difference is indeed related to the compile-time conversion where as unboxing is at runtime.
Joined: Jan 30, 2000
Joyce has this right. Some additional comments:
[Mark]: static final Integer year = 2007; as a class constant.
Making this static has nothing to do with whether it's a compile-time constant. It's not part of the requirements listed in JLS 15.28. If we're originally talking about a local variable which we are here), you might as well leave it local. If it's a compile-time constant (which this one isn't), the compiler would end up treating it the same way, putting it in the constants table.
[Thomas]: What is the meaning then of assignable in JLS 14.11?
That's one of the additional requirements. They established earlier that the expression after case must be either a constant expressions, defined in 15.28, or an enum constant name. Additionally it must be assignable to the type of the switch expression - but that doesn't change that it must be a constant expression, or an enum. An Integer cannot ever be part of a constant expression. The only reference types which can be constant expressions are Strings - and then only if they obey the other requirements of 15.28.
"I'm not back." - Bill Harding, Twister
Joined: Jan 06, 2006
I would like to add some subtle detail: Declaring "year" as final only prohibits the assignment of a new reference to "year":
But you are using which means your are using the state of "year". Ok, we all know that Integer is immutable, so the state can't be changed.
But that's the point: You are aiming at the fact, that Integer is immutable but this is an implementation detail. There is no line in the JLS where it is said that Integer has to be immutable. So the JVM can not rely on it.
The body of a switch statement is known as a switch block. Any statement immediately contained by the switch block may be labeled with one or more case or default labels. These labels are said to be associated with the switch statement, as are the values of the constant expressions (�15.28) in the case labels.
And when we check the constant expressions (�15.28) it is only talking about compile time constants.
What other kinds of constants are there than compile time constants? Are all final object refrences except String are non-compile time constants? Can you provide links?
Joined: Jan 30, 2000
When most people say "constant", they mean a compile-time constant expression. Some people would also mean things that are constant at runtime but not compile time, such as an immutable object other than String. Or a final primitive field which was initialized from a properties file at runtime. However I think it just causes confusion to call these "constants", since the most common usage seem to be to mean compile-time constant expressions. Let's just stick with that.
Note that when 14.11 talks about constant expressions (no mention of compile-time), they also give a link to 15.28 which clarifies exactly what they mean. They are really talking about compile-time constant expressions.
[jiju]: Are all final object refrences except String are non-compile time constants?
Any object which is not a String is definitely not a compile-time constant expression. And as noted above, I'd prefer not to call them constants at all.
Can you provide links?
Section 15.28 already defined what a compile-time constant expression is. Anything outside that definition is not a compile-time constant expression, period.
Joined: Oct 17, 2005
Line no 4 & 5 in above code doesn't compile for me. am i doing something wrong?
Joined: Aug 03, 2002
Originally posted by Simi gupta: Line no 4 & 5 in above code doesn't compile for me. am i doing something wrong?
That makes sense, the code exhibit will only compile with a Java 5.0 compliant compiler. The code exhibit makes use of (auto)boxing which is a new feature to the Java language from Java 5.0 onwards. [ January 10, 2006: Message edited by: Thomas De Vos ]
Joined: Oct 12, 2004
Thanks for the explanation. [url=http://"http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.11"]14.11 [/url]was confusing because it is saying "values of the constant expression".
It should have told "values of the compile time constant expression".