My doubt is why the compilation fails at line 1? Why Autoboxing is not kicked in here?
Autoboxing is not enough for this. Java requires that the cases of a switch statement be constants. Java currently only recognize primatives and strings as possible compile time constants.
Since Java can't recognize an Integer object as a constant, the unboxed value (assuming autoboxing "kicked in here") also can't be a constant. And since it isn't a constant, it can't be used as a case of a switch statement.
On the other hand, the switch part of a switch statement isn't a constant -- so autoboxing does kick in there.
Henry [ December 21, 2008: Message edited by: Henry Wong ]
This isn't directly relevant to the original question, but it's true nonetheless - and it's a fact that you may need for SCJP:
[Henry]: Java requires that the cases of a switch statement be constants.
Constants or enum values. By the time the JVM sees these, they have been converted to int constants, true. But at the language level, enum values are not considered constants. And yet they are allowed in a switch statement. So, Java requires that the case values in a switch statement be constant expressions or enum values.
I also thought that Enum values are compile time constants, and I am interested in knowing if that is not the case.
I also have another comment to make about the inability of using a final Integer as the value for a case in switch statement. Why can't Java at compile time see a final Integer reference pointing to an object initialized by a constant integer expression as a constant? Since the reference is final, it can't be reassigned to a different object, and the Integer itself is immutable, so it can't change. [ December 21, 2008: Message edited by: Ruben Soto ]
All code in my posts, unless a source is explicitly mentioned, is my own.
Joined: Oct 16, 2008
If enum values are not constant, why java specification uses the term "enum constants"JLS 8.9 eveywhere.
Joined: Dec 16, 2008
Something can be a constant but not a compile-time constant. A compile-time constant is something that the language specification has (to some degree arbitrarily) decided that the compiler won't have any difficulty determining as a constant (and grabbing its value) by just doing what compilers do (parse the code,) and without going into too much trouble. The reason why enums are allowable in switch statements is that the compiler can determine the value of an enum type literal at compile time, but they are just not "considered" compile time constants by the specification.
As for the final Integer initialized in a declaration, it could very well be allowed in a switch statement, meaning that the compiler could easily treat it the same way as a constant int reference, but it just happens that the specification doesn't allow it. Not only that, but Integers, Shorts, Bytes, and Chars are not given the status of exception that enums are as far as switch statements go. There is a degree of arbitrariness to all this, but I'm sure someone can point out why things are the way they are and not something different.
[ December 22, 2008: Message edited by: Ruben Soto ] [ December 22, 2008: Message edited by: Ruben Soto ]
Joined: Mar 05, 2008
[punit]: If enum values are not constant, why java specification uses the term "enum constants"JLS 8.9 eveywhere.
OK, good point.
I would say that "constant", by itself, is ambiguous, never really defined in the JLS.
The JLS does define "compile-time constant expression". And it does define "enum constants". A case label can use a compile-time constant, or it can use an enum constant. Though those concepts are similar, they aren't the same thing. And while it may be tempting to group them together as "constants", that can be dangerously misleading. It would be easy to think that an Integer can be a constant for example - but it's not something that can be used in a switch statement, for example. That's why I prefer to be picky about the actual definitions used.
In the past, whenever someone has referred to constants, I usually assume they mean compile-time constant expressions, unless they say otherwise. In this case that was a mistake - it's possible that "constant" was intended to include enum constants as well. Well, OK, but then what about people who think the term "runtime constant" might be meaningful? Down that road lies madness, I think. Better to just stick to what is explicitly spelled out in the rules, and not try to generalize those rules too much. If someone on these forums refers to a "constant" without further qualification, it isn't clear what they mean.
[Ruben]: There is a degree of arbitrariness to all this, but I'm sure someone can point out why things are the way they are and not something different.
I wouldn't be at all sure about that. It is indeed vary arbitrary, and there are other ways that Sun could have chosen to define things - they just didn't. Remember enums didn't even exist when "compile-time constant expression" was originally defined. They tacked that definition on later. Why didn't they refine the CTCE definition, instead of creating a new definition of an ambiguously-related term? I don't know. Maybe they were trying to avoid changing existing definitions. Or maybe the definitions were made by a committee of some sort.
Joined: Dec 12, 2008
Thanks Ranchers.Now my doubt got clarified.
Joined: Dec 16, 2008
You are right, I just didn't want to upset the powers that be, lest they may track me down and beat me up with a supersized copy of the JLS.