Convert your shifting line to this: -
byte bitMask = (byte)(0x8>>(byte)bitNumber);
Your RHS, is an int, you need to typecast it to byte..
Above code will work fine.. With or without the casting of bitNumber to byte
So, you can also have : -
byte bitMask = (byte)(0x8>>bitNumber);
But, here's is a question - byte bitMask = 0x8>>3; works fine.. Why is it so??
Here's some example to explain the reason behind its working and also the behaviour with final: -
byte bitMask;
int varInt1 = 3;
final int finalVarInt2 = 3;
final int finalVarInt3 = 4;
bitMask = 0x8>>varInt1; // 1. Will not work.
bitMask = 0x8<<3; // 2. Will work
bitMask = 0x8<<4; // 3. Will not work
bitMask = 0x8<<finalVarInt2; // 1. Will work
bitMask = 0x8<<finalVarInt3; // 2. Will not work
Here's some reasoning that explains the above behaviour: -
- The value on the RHS will be
typecasted implicitly only if, the compiler is sure that, it will be able to accomodate that value in the byte variable on LHS.. Else, we have to do Explicit type casting to tell compiler that, we know what we are doing, just do it for us..
Now lets consider all the cases one-by-one (From the above code (1-3, 1-2): -
varInt1 initially contains 3. So the value of RHS evaluates to 64. Although this value might get accomodated to byte variable in LHS, but compiler also knows that, it is possible to change the value of varInt1.. So what if value of varInt1 is changed to 4 at some stage.. It won't work then.. That's why it is not allowed..
- Now, in this case, since we have explicitly used an
Integer Literal here, so compiler is sure that it will accomodate in byte.. So it allows the implicit casting..
- Again, in this case, it is known that
RHS will evaluate to 128 which can't be accomodated in byte.. Failed again..
Last two cases are different from regular variables... Since they are declared final, they can't be re-initialized.. So, compiler can make a decision based on the assigned value..
In this case, compiler sees that, finalVarInt2 contains value 3. So, RHS evaluates to 64, which can be accommodated in the byte variable on LHS. Now, since the variable is final it can't be changed, and Compiler knows that, so it is sure that t*his value will always be 64*.. So compiler allows this.
In the last case, value of finalVarInt3 is 4.. Similar reasoning.. Won't fit in LHS, as RHS evaluates to 128 which can't fit into byte