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