为何Hadoop WritableComparator的compareBytes需用变量a、b而非直接比较？

I'm diving into Hadoop's source code and came across this method in org.apache.hadoop.io.WritableComparator:

public static int compareBytes(byte[] b1, int s1, int l1, byte[] b2, int s2, int l2) {
    int end1 = s1 + l1;
    int end2 = s2 + l2;
    for (int i = s1, j = s2; i < end1 && j < end2; i++, j++) {
        int a = (b1[i] & 0xff);
        int b = (b2[j] & 0xff);
        if (a != b) {
            return a - b;
        }
    }
    return l1 - l2;
}

My question is: Why do we need to use intermediate variables a and b for comparison, instead of comparing b1[i] and b2[j] directly?

Great question! The core reason boils down to how Java handles signed bytes versus the requirement for unsigned byte comparison in this method. Let's break it down step by step:

• In Java, the byte type is signed, meaning it ranges from -128 to 127. So a raw byte value like 0xff (which is 255 in unsigned terms) gets represented as -1 when treated as a signed byte.
• If we compared b1[i] and b2[j] directly, we'd be doing a signed comparison. That's a problem because this method is meant to compare raw byte sequences as unsigned 8-bit values (0 to 255) — a standard requirement for serialization and data storage systems like Hadoop.

For example:

• Suppose b1[i] is 0xff (signed byte -1) and b2[j] is 0x00 (signed byte 0). A direct comparison would incorrectly treat -1 < 0, but as unsigned bytes, 255 > 0 — which is the logical, correct result for byte sequence ordering.

The & 0xff operation fixes this by converting the signed byte to an int that represents its unsigned value:

• This operation takes the 8-bit signed byte, extends it to 32 bits, and masks out all bits except the original 8. So -1 (byte) becomes 255 (int), 127 stays 127, and -128 becomes 128.

The intermediate variables a and b serve two purposes:

1. Clarity: They make it explicit that we're working with unsigned integer representations of the bytes, rather than the raw signed values. This makes the code easier to read and maintain for other developers.
2. Correctness: By storing these converted values, we ensure that the subsequent subtraction a - b returns the right positive/negative/zero result to indicate the relative order of the bytes.

You could technically inline the conversion and subtraction (like return (b1[i] & 0xff) - (b2[j] & 0xff)), but the variables make the intent of the code far more obvious.

内容的提问来源于stack exchange，提问作者TechieYu