What Does Value & 0Xff Do in Java

What does value & 0xff do in Java?

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.}

Why is & 0xff applied to a byte variable

The literal 0xff is, as per the JLS, of type int.

Also as per the JLS, when an operation is performed between a byte and and int, the byte is safely widened to an int and the result is an int.

What this means is that the expression:

hash[offset + 1] & 0xff

Is more or less the same as:

(int)(hash[offset + 1]) & 0xff

In fact, an int is needed as the result type for the following bit-shift operation to make sense.

(hash[offset + 1] & 0xff) << 16

If the bit-shift was done on a byte, the bits would just rotate back to their original position (16 being an exact multiple of 8).

The whole code is constructing an int from a byte[].

The odd mask 0x7f used on the high byte is used instead of 0xff to mask off the left-most (or most significant) bit, which is the sign bit, to ensure the final result is not negative.

What does & 0xff do?

It's a so-called mask. The thing is, you get the RGB value all in one integer, with one byte for each component. Something like 0xAARRGGBB (alpha, red, green, blue). By performing a bitwise-and with 0xFF, you keep just the last part, which is blue. For other channels, you'd use:

int alpha = (rgb >>> 24) & 0xFF;
int red   = (rgb >>> 16) & 0xFF;
int green = (rgb >>>  8) & 0xFF;
int blue  = (rgb >>>  0) & 0xFF;

In the alpha case, you can skip & 0xFF, because it doesn't do anything; same for shifting by 0 in the blue case.

What does AND 0xFF do?

Anding an integer with 0xFF leaves only the least significant byte. For example, to get the first byte in a short s, you can write s & 0xFF. This is typically referred to as "masking". If byte1 is either a single byte type (like uint8_t) or is already less than 256 (and as a result is all zeroes except for the least significant byte) there is no need to mask out the higher bits, as they are already zero.

See tristopiaPatrick Schlüter's answer below when you may be working with signed types. When doing bitwise operations, I recommend working only with unsigned types.

What do & and 0xff mean

Further explanation of the bit arithmetic. Let's assume the int bits look as follows:

00000000 10101010 01010101 11011011
unused   red      green    blue

To get the int value for blue, you want all bits other than the lower 8 turned off. The easy way to do this is with a bitwise and. 0xff can also be written as 0x000000ff, which will set the upper 24 bits to 0, and only turn on the bits in the lower 8 which are already set to 1.

argb & 0xff ==> 00000000 00000000 00000000 11011011
                                           blue

argb >> 8 ==> 00000000 00000000 10101010 01010101 
                                red      green
(argb >> 8) & 0xff ==> 00000000 00000000 00000000 01010101 
                                                  green

argb >> 16 ==> 00000000 00000000 00000000 10101010
                                          red
(argb >> 16) & 0xff ==> 00000000 00000000 00000000 10101010
                                                   red

even thought the & 0xff on the red value seems unecessary, there's no guarantee the caller might not have set some of the high order unused bits, so you want to be safe and turn all of them off.

What does & 0xff do And MD5 Structure?

Presumably most of the code is clear and the only mystery for you here is this expression:

(bytes[i] & 0xff) + 0x100

The first part:

bytes[i] & 0xff

widens the byte at position i to an int value with zeros in bit positions 8-31. In Java, the byte data type is a signed integer value, so the widening sign-extends the value. Without the & 0xff, values greater than 0x7f would end up as negative int values. The rest is then fairly obvious: it adds 0x100, which simply turns on the bit at index 8 (since it is guaranteed to be 0 in (bytes[i] & 0xff). It is then converted to a hex String value by the call to Integer.toString(..., 16).

The reason for first adding 0x100 and then stripping off the 1 (done by the substring(1) call, which takes the substring starting at position 1 through the end) is to guarantee two hex digits in the end result. Otherwise, byte values below 0x10 would end up as one-character strings when converted to hex.

It's debatable whether all that has better performance (it certainly isn't clearer) than:

sb.append(String.format("%02x", bytes[i]));

bitwise-ANDing with 0xff is important?

Yes, 0xff is just 1111 1111. But this is attempting to display the unsigned byte value, even though in Java bytes are signed. The value 0xff is -1 for a signed byte, but it's 255 in a short.

When a byte value of 0xff is read, printing the value would yield -1. So it's assigned to a short which has a bigger range and can store byte values that would normally overflow to be a negative number as a byte as a positive integer, e.g. 144 as a byte is 0x90, or -112, but it can be properly stored as 144 as a short.

So the byte value of -1 is assigned to a short. But what does that do? A primitive widening conversion takes place, and negative values are sign-extended. So 1111 1111 becomes 11111111 11111111, still -1, but this time as a short.

Then the bitmask 0xff (00000000 11111111) is used to get the last 8 bits out again:

  -1: 11111111 1111111
0xFF: 00000000 1111111
======================
 255: 00000000 1111111

It's just a way to get the unsigned byte value, by converting it to short and then masking out the original bits from the byte, to display it as an unsigned value.

What does 0xff n do in Java?

some thing like these ?

Yes, except that the operands undergo numeric promotion and turns into an int, so you should technically show 32 bits.

and why we need use the mask & 0xff?

This is so we treat negative bytes as positive ints, essentially what toUnsignedInt is doing. It doesn't do anything for non-negative bytes, but for a negative byte, say -1:

1111 1111

When that gets converted to int due to numeric promotion, it will be sign-extended to 32-bits. That is, the sign will stay negative. Basically this means that if the number is negative, we pad 1s, otherwise we pad 0s. So -1 becomes:

1111 1111 1111 1111 1111 1111 1111 1111

Now if you use the << 8 on that, it will be:

1111 1111 1111 1111 1111 1111 0000 0000

which is -256. Now let's see what happens if you do & 0xff before << 8. Numeric promotion happens, and converts your byte to 32 ones just like before, but & 0xff gets only the 8 least significant bits! So the int now becomes:

0000 0000 0000 0000 0000 0000 1111 1111

This is how you get your original byte, padding with 0s. And then << 8 does the obvious thing:

0000 0000 0000 0000 1111 1111 0000 0000

I don't know the mean of i[1]=data[1]& 0xff;

getBinaryStream() doc

Retrieves the BLOB value designated by this Blob instance as a stream.

Returns:

a stream containing the BLOB data.

The hex literal 0xFF is an equal int value 255. Java represents int as 32 bits.

Binary value of 0xFF

0xFF = 00000000 00000000 00000000 11111111

number & 0xff reference

The & operator performs a bitwise AND operation. data[1]& 0xff will give you an integer with a bit pattern.

The rule of & operator is

1&0=0

1&1=1

0&0=0

0&1=0

So when you do a & with this 0xFF on any number, it is going to make 0s all but leaves only the value in the last 8 bits.

For example, the bitwise AND of 10110111 and 00001101 is 00000101.

10110111

&

00001101

=

00000101

---

Related Topics