What does value & 0xff do in Java?
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?
Solution 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
values1, so what happens is:
-
value
is promoted to anint
(ff ff ff fe
). -
0xff
is anint
literal (00 00 00 ff
). - The
&
is applied to yield the desired value forresult
.
(The point is that conversion to int
happens before the &
operator is applied.)
1Well, 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.
Solution 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;