This week's book giveaway is in the Design forum. We're giving away four copies of Building Microservices and have Sam Newman on-line! See this thread for details.

Here 0x88 = -120. When we do the bitwise AND, its implicitely converted to an integer and since 0xff = 255, we should get the same number as output. So, the variable i must be equal to -120. Why am I getting a positive result (136).

Are the extra bits simply added(prefixed) without maintaining the negative sign. If that's the case, then the answer is fine. But why is this so.

So, is (byte)0x88 is automatically converted to 0x00000088 while performing the bitwise AND. Then why doesn't

convert 0x88 to 0x00000088. Here, it uses the negative value.

What I want to ask is that while doing bitwise operation, the sign bit is not taken into consideration and zeros are blindly prefixed. But while doing non-bitwise operations such as addition, multiplication etc, the sign bit is not compromised with. Why?

So, is (byte)0x88 is automatically converted to 0x00000088 while performing the bitwise AND. Then why doesn't ...

No, that is not what is happening... When a byte is casted to an integer the sign bit is extended out. So, 0x88 as byte should covert to 0xffffff88 as an integer.

The issue is the AND operation... 0xffffff88 & 0x000000ff => 0x00000088