aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Switch Statement Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Switch Statement" Watch "Switch Statement" New topic
Author

Switch Statement

Sushant Kaushik
Greenhorn

Joined: Dec 12, 2008
Posts: 25
Hello Ranchers,
Source - K &B Self Test,Chapter 5,Q 13.


My doubt is why the compilation fails at line 1? Why Autoboxing is not kicked in here?

Thanks,
Sushant
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19073
    
  40

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 ]

Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
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.
Punit Singh
Ranch Hand

Joined: Oct 16, 2008
Posts: 952
Ohhh ...

But at the language level, enum values are not considered constants.


I have doubt on this statement, I was thinking enum values are considered constants.


SCJP 6
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Well, constant expressions are defined in JLS 15.28. Do you see any reason to think that enum types are included in this?
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
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.
Punit Singh
Ranch Hand

Joined: Oct 16, 2008
Posts: 952
If enum values are not constant, why java specification uses the term "enum constants"JLS 8.9 eveywhere.
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
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 ]
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
[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.
Sushant Kaushik
Greenhorn

Joined: Dec 12, 2008
Posts: 25
Thanks Ranchers.Now my doubt got clarified.

Thanks,
Sushant
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
Mike:

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Switch Statement