30
        //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.

RzR
  • 3,068
  • 29
  • 26
defectivehalt
  • 2,462
  • 3
  • 21
  • 22
  • For reference: http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.6.2 and http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#5233. I don't know the rationale, so I'm not posting an answer. – Michael Myers Jan 04 '10 at 23:22
  • Seconded. I couldn't find anything describing *why* the above occurs, just that it does. – Brian Agnew Jan 04 '10 at 23:24
  • 1
    Type promotion exists for several reasons. For bitwise operations it would make much less sense than for nearly all others, but then - why not? You can always cast it back. – Pavel Radzivilovsky Jan 04 '10 at 23:27
  • Because Java is already far too verbose for yet another needless cast. – Elazar Jan 05 '15 at 15:42

4 Answers4

20

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.
Michael Borgwardt
  • 342,105
  • 78
  • 482
  • 720
5

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);
RzR
  • 3,068
  • 29
  • 26
2

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.

Victor Nicollet
  • 24,361
  • 4
  • 58
  • 89
  • Again, the question was *why* this happens. – Michael Myers Jan 04 '10 at 23:25
  • 2
    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?" – mletterle Jan 04 '10 at 23:29
  • 3
    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. – Michael Borgwardt Jan 04 '10 at 23:36
0

This was somewhere down in the answers to one of the similar questions that people have already pointed out:

http://blogs.msdn.com/oldnewthing/archive/2004/03/10/87247.aspx

Licky Lindsay
  • 1,048
  • 6
  • 10