This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
When the switch statement is executed, first the Expression is evaluated. If the Expression evaluates to null, a NullPointerException is thrown and the entire switch statement completes abruptly for that reason. Otherwise, if the result is of a reference type, it is subject to unboxing conversion (§5.1.8). If evaluation of the Expression ....
Joined: Sep 12, 2009
Thanks a lot sir !!!
But in accordance with docs , the following two usages of switch statement must be same , but indeed they are different , second program will show compile time error.
Program 1 :-
This program would compile fine. No problem !!!
Program 2:- This is essentially same the above code according to docs , but shows compile time error.
But but but, if the case would be like , case constants are boxed , ie option 2, then in accordance to it, the above two codes behaviour could be reasoned.
Sahil has put a good question the program 2 specified by him certainly looks like a benign java code that should run fine but it is throwing a compile time error
switchlochaTst.java:8: incompatible types
found : char
required: java.lang.Integer case 's': break;
I am quite perplexed by this error as according to JLS the wrapper object is unboxed to int and as 's' being a character it is implicitly cast to int so everything should work fine. So ranchers need your help in understanding the reason for the error
's' needs to be explicitly declared as an int or type Integer.
it is so because in the second switch statement we are not providing a constant as an expression but a reference to an Integer ... which certainly will look for integers only ... i think char is an int but not Integer type.
1. Boxing/Unboxing is done by the compiler not JVM.
2. The switch expression is unboxed as given in the spec.
3. The spec also says that the case constants must be compatible with the switch expression. This is why the following code fails to compile
's' is not compatible with the switch expression (as Integer i = 's'; won't compile). Although the switch expression will be unboxed and after that 's' will be compatible with the unboxed value 30, but the compiler also have to ensure that the case constants are compatible with the switch expression before the unboxing takes place...
Actually, compiler does compatibility test between case constant and the evaluated type of the switch expression, that is, it checks whether the type and the value of the case constant is assignable in the evaluated type of the switch expression. As a result the following codes will compile and run as usual:
Eclipse uses a different compiler than the normal javac compiler we use from the command prompt. I think Eclipse uses an IBM compiler but I'll have to look into the details to be sure. The compiler used by Eclipse behaves differently than the JDK compiler on many occasions. For SCJP you should always rely on the JDK compiler and not any IDE...
When you use == operator, if one of the operands is a primitive and the other is a wrapper class, the wrapper is unboxed. So in your case i is unboxed to int, then a is promoted to int and then the conversion is done...
Ankit Garg wrote:When you use == operator, if one of the operands is a primitive and the other is a wrapper class, the wrapper is unboxed. So in your case i is unboxed to int, then a is promoted to int and then the conversion is done...
Ankit is right ...
wrapper in unboxed to the primitive type always ...
and since char is internally an int .. it is promoted to an int before == checking ...
in case of the switch statement ... since the actual expression is evaluated only before being converted or unboxed or promotion ... this happens
Joined: Feb 17, 2010
Lalit Mehra wrote:in case of the switch statement ... since the actual expression is evaluated only before being converted or unboxed or promotion ... this happens
I assume this is not correct behavior, even though we know it is behaving like this. I am trying to understand logic behind this behavior. Is there any logical reason why compiler behave like this.
from the logical thinking, I think switch as multiple if else, may be implementation wise there is difference the way if and switch statement converted into byte code.
Or may be I am thinking too much, I should accept this or move on?
Pradeep- Kumar wrote:from the logical thinking, I think switch as multiple if else, may be implementation wise there is difference the way if and switch statement converted into byte code.
Well yes logically you can think of switch as multiple if else. But the rules for if-else don't apply to switch. The case constants are not compared to the switch expression with == operator. Switch statement is a construct in itself. So the case constants need to be compatible with the switch expression, the JLS doesn't say that the case constants must be compatible with the switch expression *after* the switch expression is unboxed...