What does 0xff <<n do in Java?

From a Inputstream , i read the first 4 Bytes and packed these to obtain
some information in this case the size/len of the Stream.

For that i use follow code (Example 1) that i copy from another project

Example 1: uses a byte array,where the values are read from InputStream into the array named in_buf[] with lenght 4 and which values are {0,0,12,26}.

Example 1

int size = (((in_buf[0] & 0xff) << 24) | ((in_buf[1] & 0xff) << 16) |
            ((in_buf[2] & 0xff) << 8) | (in_buf[3] & 0xff)); // result its 3098

and as a result i become the value of the size , nice but..

i need to explain what happens here,
and i try to split all the function to see better what happens and debug , and i become following results

    int byte1 = ((in_buf[0] & 0xff) << 24); // result 0
    int byte2 = ((in_buf[1] & 0xff) << 16); // result 0
    int byte3 = ((in_buf[2] & 0xff) << 8);  // result 3072
    int byte4 = (in_buf[3] & 0xff);         // result 26

then i deduce that from Example 1 the result of size ist the sume of 0+0+3072+26
but what exacly happens (only with value 12 and 26) here? or which operation it's maked?

Something like this ?

0000 0000 0000 1100  //12  << 8
0000 1100 0000 0000  // result after << 8

And why we need use the mask & 0xff ?

cuz when you debug int byte3a = (in_buf[3] & 0xff) the result ist same that int byte3b = in_buf[3]; so 12, *where value of in_buf[3]=12 ; I add a image from my debug results.

What happens or make this in_buf[3] & 0xff , something like?

  0000 0000 0000 1100 (12)
& 0000 0000 1111 1111 (0xff)
  -------------------
  0000 0000 1111 0011 ?

Screenshot from Eclipse

> 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

The shown code in example1 takes the first four values of the array (which presumably contains what you describe as "the input stream", or its values). It arranges them into a single variable, presumably an (unsigned) integer one of sufficient width.

It does so in order to get what is presumably the semantic meaning of the first four values, according to a protocol you did not specify.

So, why do so in that "roundabout" way, using those operators?

The use of & 0xff makes sure that only the lower 8 bit are used.
This is redundant, i.e. unneeded, in case you can rely on the values in the array coming from bytes and hence only containing values up to bit 7. Without any higher bits (valued 256, 512, ...) are taken into account. This makes sense if you do not trust the retrieval of single bytes from the stream into the array.
However in java (as harold kindly pointed out in a comment)
> & 0xff is not redundant in Java because byte is a signed type, and hence sign-extended when converted to int, and those extra copies of the sign need to be removed. If byte was unsigned it would save a lot of code like this.

The use of << N, with N being multiples of 8, moves the eight "harvested" bits into the position inside the result value, where they have the correct influence on the result value. One of the bytes (I intentionally do not use "first" here) belongs into the lowest-valued position, it is not shifted, its value is used as is. One byte is need as the next higher valued byte, i.e. representing multiples of 256 (0x100). And so on.

The use of | assembles the correctly located parts.

Now why do that in this complicated way? The obvious alternative is to just kill all bits beyond bit 7 and then read the lot as one 4byte integer.
The reason is doubt on endianess. You might not trust that arranging four bytes in a certain order in memory will, if read as one 4byte value, will be interpreted as the value you target in your environment. This is because different environments can be of different opinion whether the byte at the lowest address should be considerd the one representing the lowest values or the highest values.
The shown code forces a selected byte to the high values, one to the low values and the others in between.

It will force the value into an 8-bit byte.

Since Java has no unsigned types, a byte value of 0xFF is interpreted as -1 and due to Java's nature it will be promoted to a 32-bit int, i.e. 0xFFFFFFFF.

The bitmask is meant to discard those extra bits for negative values so they don't overwrite the bits when using the OR bitwise operator |.

Here's an example with the byte value being 255, although interpreted as -1 and promoted to int

  1111 1111 1111 1111 1111 1111 1111 (-1, but was originally an unsigned byte of 255)
& 0000 0000 0000 0000 0000 1111 1111 (0xff)
  ----------------------------------
  0000 0000 0000 0000 0000 1111 1111 (an int with the original value of 255)

These are binary operations.

What exactly happens?

the & 0xFF basically means, you take the last byte.

Binary and (&) means, on the result position will be 1 only if 1 is in both numbers at the same position (0 otherwise).

There is another example:

  0000 0001 0000 1100 (268)
& 0000 0000 1111 1111 (0xff)
  -------------------
  0000 0000 0000 1100 (12)

What happens with 12?

  0000 0000 0000 1100 (12)
& 0000 0000 1111 1111 (0xff)
  -------------------
  0000 0000 0000 1100 (12)

shift:

left shift just pushes the bits to the left.

  0000 0000 0000 1100 (12)
<< 8
  -------------------
  0000 1100 0000 0000 (3072)

What happens with 26?

  0000 0000 0001 1010 (26)
& 0000 0000 1111 1111 (0xff)
  -------------------
  0000 0000 0001 1010 (26)

why we need use the mask & 0xff ?

In this case, you don't. But if you worked with larger numbers (or negative numbers), there might be a need to use the mask. Also, you make sure, there are no extra messy bits.

Putting it all together with or:

Yes, it's basically addition, but only in this case. What actually happens is you put the bytes you created with & 0xFF next to each other to create a number. That is the reason you are shifting by multiplies of 8 - every byte has own place of size 8.

let's say you have bytes X,Y,Z,W.
Then (X<<24)|(Y<<16)|(Z<<8)|W will create number constructed in binary as followed: XYZW. Watch out, it doesn't have to be sum of these numbers.