Java ByteBuffer byte order: decode the protocol before reading integers

This complete program targets Java 8. Its displayed output is checked by the tutorial validation script.

The bytes have a format, not a machine preference

The receipt header uses four bytes with the value one in little-endian order. Reading the same bytes with the default big-endian order produces 16777216. Both reads are mechanically valid; only one matches the protocol. Set the agreed order explicitly before reading an integer.

The duplicate shares the same bytes but has its own position and order setting. The fixture changes the original to little-endian and observes that the duplicate still reads its own configured order. A buffer view is not a decoded value, and sharing storage is different from sharing cursor state.

Bound the header first

The parser rejects a header that is not exactly four bytes before reading. A larger message needs bounds for each field, declared payload length and total retained bytes. Treating a transmitted length as a trusted allocation request can turn an ordinary header parser into an oversized allocation path.

An unsigned field also needs a deliberate Java representation. Byte order does not solve signedness. See Byte input before assuming that an integer read validates a complete packet or verifies who sent it.

Working program

import java.nio.*;
public class ReceiptHeaderOrder {
    static int read(byte[] header) {
        if(header.length!=4)throw new IllegalArgumentException("four-byte header required");
        return ByteBuffer.wrap(header).order(ByteOrder.LITTLE_ENDIAN).getInt();
    }
    public static void main(String[] args) {
        byte[] bytes={1,0,0,0};ByteBuffer original=ByteBuffer.wrap(bytes);
        ByteBuffer view=original.duplicate();original.order(ByteOrder.LITTLE_ENDIAN);
        System.out.println(original.getInt());System.out.println(view.getInt());System.out.println(read(bytes));
        try{read(new byte[3]);}catch(IllegalArgumentException rejected){System.out.println("length rejected");}
    }
}

Output

1
16777216
1
length rejected

Costs and boundaries

The fixed four-byte read has bounded time and storage. Wrapping shares the supplied byte array; it is not a defensive copy. Larger protocols must budget retained byte buffers and reject lengths before allocating or reading their declared payloads.

Common Mistakes

• Use protocol byte order, not host assumptions.
• Configure each view according to its read contract.
• Validate field length before primitive access.

Read next

Java byte streams: partial reads and bounded copying, Java file channels: buffer positions and partial transfers, Java foreign memory: arena lifetime, bounds and thread ownership.