Why does the xor operator on two bytes produce an int?

Question

        //key & hash are both byte[]
        int leftPos = 0, rightPos = 31;
        while(leftPos < 16) {
            //possible loss of precision. required: byte, found: int
            key[leftPos] = hash[leftPos] ^ hash[rightPos];
            leftPos++;
            rightPos--;
        }

Why would a bitwise operation on two bytes in Java return an int? I know I could just cast it back to byte, but it seems silly.

Solution 1

Because the language spec says so. It gives no reason, but I suspect that these are the most likely intentions:

• To have a small and simple set of rules to cover arithmetic operations involving all possible combinations of types
• To allow an efficient implementation - 32 bit integers are what CPUs use internally, and everything else requires conversions, explicit or implicit.

Solution 2

If it's correct and there are no value that can cause this loss of precision, in other words : "impossible loss of precision" the compiler should shut up ... and need to be corrected, and no cast should be added in this :

byte a = (byte) 0xDE; 
byte b = (byte) 0xAD;
byte r = (byte) ( a ^ b);

Solution 3

There is no Java bitwise operations on two bytes. Your code implicitly and silently converts those bytes to a larger integer type (int), and the result is of that type as well.

You may now question the sanity of leaving bitwise operations on bytes undefined.

Comments

[palantus]

Again, the question was why this happens.

[mletterle]

That is why it happens, the question I think you're looking for is "Why did they decide to leave bitwise operators on the byte type undefined necessitating the implicit cast to int?"

[Michael Borgwardt]

The operations are not undefined; in fact they are defined quite clearly. It's just that the result is an int and cannot be stored in a byte[] without explicit casting.

[mletterle]

Using native 32bit CPU operations is the most likely reason.

[defectivehalt]

None of those examples include a bitwise operator, which to my knowledge can not cause overflow/underflow.