What does value & 0xff do in Java?

Question

I have the following Java code:

byte value = 0xfe; // corresponds to -2 (signed) and 254 (unsigned) int result = value & 0xff; 

The result is 254 when printed, but I have no idea how this code works. If the & operator is simply bitwise, then why does it not result in a byte and instead an integer?

Answer 1

It sets result to the (unsigned) value resulting from putting the 8 bits of value in the lowest 8 bits of result.

The reason something like this is necessary is that byte is a signed type in Java. If you just wrote:

int result = value; 

then result would end up with the value ff ff ff fe instead of 00 00 00 fe. A further subtlety is that the & is defined to operate only on int values¹, so what happens is:

1. value is promoted to an int (ff ff ff fe).
2. 0xff is an int literal (00 00 00 ff).
3. The & is applied to yield the desired value for result.

(The point is that conversion to int happens before the & operator is applied.)

1_{Well, not quite. The & operator works on long values as well, if either operand is a long. But not on byte. See the Java Language Specification, sections 15.22.1 and 5.6.2.}

Answer 2

From http://www.coderanch.com/t/236675/java-programmer-SCJP/certification/xff

The hex literal 0xFF is an equal int(255). Java represents int as 32 bits. It look like this in binary:

00000000 00000000 00000000 11111111 

When you do a bit wise AND with this value(255) on any number, it is going to mask(make ZEROs) all but the lowest 8 bits of the number (will be as-is).

... 01100100 00000101 & ...00000000 11111111 = 00000000 00000101 

& is something like % but not really.

And why 0xff? this in ((power of 2) - 1). All ((power of 2) - 1) (e.g 7, 255...) will behave something like % operator.

Then
In binary, 0 is, all zeros, and 255 looks like this:

00000000 00000000 00000000 11111111 

And -1 looks like this

11111111 11111111 11111111 11111111 

When you do a bitwise AND of 0xFF and any value from 0 to 255, the result is the exact same as the value. And if any value higher than 255 still the result will be within 0-255.

However, if you do:

-1 & 0xFF 

you get

00000000 00000000 00000000 11111111, which does NOT equal the original value of -1 (11111111 is 255 in decimal).

Few more bit manipulation: (Not related to the question)

X >> 1 = X/2 X << 1 = 2X 

Check any particular bit is set(1) or not (0) then

 int thirdBitTobeChecked =   1 << 2   (...0000100)  int onWhichThisHasTobeTested = 5     (.......101)   int isBitSet = onWhichThisHasTobeTested  & thirdBitTobeChecked;  if(isBitSet > 0) {   //Third Bit is set to 1   }  

Set(1) a particular bit

 int thirdBitTobeSet =   1 << 2    (...0000100)  int onWhichThisHasTobeSet = 2     (.......010)  onWhichThisHasTobeSet |= thirdBitTobeSet; 

ReSet(0) a particular bit

int thirdBitTobeReSet =   ~(1 << 2)  ; //(...1111011) int onWhichThisHasTobeReSet = 6      ;//(.....000110) onWhichThisHasTobeReSet &= thirdBitTobeReSet; 

XOR

Just note that if you perform XOR operation twice, will results the same value.

byte toBeEncrypted = 0010 0110 byte salt          = 0100 1011  byte encryptedVal  =  toBeEncrypted ^ salt == 0110 1101 byte decryptedVal  =  encryptedVal  ^ salt == 0010 0110 == toBeEncrypted :) 

One more logic with XOR is

if     A (XOR) B == C (salt) then   C (XOR) B == A        C (XOR) A == B 

The above is useful to swap two variables without temp like below

a = a ^ b; b = a ^ b; a = a ^ b; 

OR

a ^= b ^= a ^= b;