Bitwise Computing in Java: AND, OR, XOR, Shift, and Complement

Bitwise operators work on the individual bits of an integral value. In Java they accept byte, short, char, int and long, and they are rejected on boolean, float and double.

The single most common mistake is writing & or | when you meant && or ||. They look similar and behave very differently, as section 10 shows. There is also no ~ for logical negation; that is !.

Each operator follows its own truth table, applied to every bit position independently. Nothing carries between positions, there is no arithmetic and no overflow behaviour to think about.

AND & OR | XOR ^ a b -> r a b -> r a b -> r -------- -------- -------- 0 0 -> 0 0 0 -> 0 0 0 -> 0 0 1 -> 0 0 1 -> 1 0 1 -> 1 1 0 -> 0 1 0 -> 1 1 0 -> 1 1 1 -> 1 1 1 -> 1 1 1 -> 0

Here is the classic worked example, one bit position at a time.

a = 0b1100 = 12 b = 0b1010 = 10 a b 1100 1010 ---- ---- AND 1000 = 8 only the bit set in both survives ---- ---- OR 1110 = 14 every bit set in either survives ---- ---- XOR 0110 = 6 the bits that disagree

int a = 0b1100;
// 12
int b = 0b1010;
// 10
System.out.println(a & b);
// 8
System.out.println(a | b);
// 14
System.out.println(a ^ b);
// 6

Java also accepts the 0b prefix for binary literals, added in Java 7, which makes this far easier to read than decimal. Underscores may be used for grouping.

int mask = 0b1010_1010;
long big = 0xFFFF_FFFF_FFFF_FFFFL;

~ flips every bit of the value. As covered in the unary operators topic, in two's complement that is exactly the same as negating and subtracting one, so ~n equals -(n + 1).

int a = 0b1100;
// 12
System.out.println(~a);
// -13
System.out.println(~a == -(a + 1));
// true
System.out.println(~~a == a);
// true

The clearing idiom mask & ~FLAG depends on this, because ~FLAG turns a single-bit mask into an all-ones-except-that-bit value.

The shifts are where Java causes the most confusion, because one of the three behaves differently from the other two.

Left shift is always the same, because shifting a positive value up cannot change the sign.

System.out.println(12 > 2);
//  3, which is 12 / 4
System.out.println(1

The right shifts only differ once the value is negative, and then the difference is stark.

-8 as a 32 bit two's complement number

          11111111 11111111 11111111 11111000

        -8 >> 1      arithmetic, copies the leading 1 into the hole

          11111111 11111111 11111111 11111100   =  -4

        -8 >>> 1     logical, fills the hole with zeros

          01111111 11111111 11111111 11111100   =  2147483644

        the value is the same either way, 2147483644 is the correct reading of -8 / 2
        when you treat the bits as unsigned:  4294967288 / 2 = 2147483644

int n = -8;
System.out.println(n >> 1);
// -4
System.out.println(n >>> 1);
// 2147483644, a large positive number
System.out.println(n >> 31);
// -1, every bit is a 1
System.out.println(n >>> 28);
// 15, the low four bits, all ones

A handy trick with >>> is isolating the low bits of a negative number, since >> would drag sign ones down through the result while >>> leaves zeros in the high end.

This is the detail that surprises experienced programmers coming from C. Java does not require the shift count to be less than the width, and it does not treat an out-of-range count as an error. It masks the count down to the width of the type being shifted.

for an int the count is masked with 0x1f(31) for a long the count is masked with 0x3f(63) so the effective shift is always: count & 0x1f for int count & 0x3f for long 1 1

System.out.println(1

Negative counts are not rejected either. They are masked the same way, and -1 has every bit set, so masking it gives the largest legal shift.

System.out.println(1

That last pair is why a shift by a variable that happens to be negative produces a baffling result. Always mask a shift count you do not control yourself, and remember that for an int the mask is 0x1f, not 0xff.

Java has only signed integers, so int runs from -2147483648 to 2147483647. Many low-level formats, such as IPv4 addresses and file sizes, are naturally unsigned, which leaves three options: shift with >>> and convert explicitly, use the unsigned helper methods on the wrapper classes, or store the value in a long.

int n = -1;
System.out.println(n > 0);
// false, signed comparison
System.out.println(Integer.compareUnsigned(n, 0) > 0);
// true, unsigned comparison
System.out.println(Integer.toUnsignedString(n));
// 4294967295
System.out.println(Integer.divideUnsigned(n, 2));
// 2147483647

The full set of unsigned helpers on Integer and Long covers comparison, division, remainder, string conversion and parsing.

A worked example, unpacking an IPv4 address stored in one int.

int ip =(192 24) & 0xFF;
int octet2 =(ip >>> 16) & 0xFF;
int octet3 =(ip >>> 8) & 0xFF;
int octet4 = ip & 0xFF;
System.out.println(octet1 + "." + octet2 + "." + octet3 + "." + octet4);

192.168.1.100 ip >>> 24 moves the top octet down to the bottom & 0xFF masks it to exactly one byte, discarding the rest this is the standard unpack pattern: shift, then mask

Testing the lowest bit tells you whether a number is even, and it avoids a division entirely.

System.out.println(42 & 1);
// 0, so 42 is even
System.out.println(43 & 1);
// 1, so 43 is odd

The same trick gives you a fast test for divisibility by any power of two, because n % 8 and n & 7 always agree.

System.out.println((45 & 7) ==(45 % 8));
// true
System.out.println(42 & 7);
// 2
System.out.println(45 & 7);
// 5

Because 7 is 111 in binary, ANDing with it keeps only the low three bits, which is exactly what the remainder operation computes.

This is the most common real use of these operators. Each flag gets one bit, so a whole set of booleans fits inside a single int.

int flags = 0;
int FLAG_READ = 1

Declaring each flag as 1 << n rather than writing the decimal number makes the intent obvious and stops anyone from wondering which bit is which.

static final int FLAG_READ = 1

The interview answer is to use the fact that XOR is its own inverse: a ^ a is 0 and a ^ 0 is a, so XORing the same value twice cancels out.

a ^ a == 0 XOR a value with itself gives zero a ^ 0 == a XOR with zero gives it back unchanged three steps swap two variables with no temporary start: a = 5, b = 9 step 1 a = a ^ b a = 5^9 = 12, b = 9 step 2 b = a ^ b b = 12^9 = 5, a = 12 step 3 a = a ^ b a = 12^5 = 9, b = 5 end: a = 9, b = 5 swapped

int a = 5, b = 9;
a = a ^ b;
b = a ^ b;
a = a ^ b;
System.out.println(a + ", " + b);
// 9, 5

The compound form does the same thing more concisely.

int a = 5, b = 9;
a ^= b;
b ^= a;
a ^= b;
System.out.println(a + ", " + b);
// 9, 5

Two points worth keeping straight. First, the swap is genuinely correct even when the two values are equal, which is the fault many people claim: swapping 7 and 7 leaves both at 7, and swapping 0 and 0 leaves both at 0. Second, do not do this in real code. It is slower than a plain temporary variable on modern processors, which can execute the three loads and stores in parallel, and it is far harder to read. Know it for interviews; use a temporary for production.

int a = 5, b = 9;
int temp = a;
a = b;
b = temp;
System.out.println(a + ", " + b);
// 9, 5, and readable

Java has both a bitwise and a logical form of AND and OR, and they behave very differently on boolean values. & and | always evaluate both sides, while && and || short-circuit and skip the right-hand side when the answer is already known.

static boolean t() {
    System.out.println("  t() called");
    return true;
}static boolean f() {
    System.out.println("  f() called");
    return false;
}boolean r = f() & t();
// calls both, t() is evaluated needlessly
boolean r2 = f() && t();
// f() is false, so t() is never called

f() & t() -> f() called t() called result false, both sides ran f() && t() -> f() called result false, t() was skipped entirely

For int operands the distinction is not optional, because only & and | work on them.

For ordinary conditions always use && and ||. The bitwise versions exist for the flag arithmetic shown earlier, not for combining tests.

The equality operators bind more tightly than the bitwise ones, which is a genuine trap.

System.out.println(5 ^ 5 == 0);
// does not compile
System.out.println((5 ^ 5) == 0);
// true

== is evaluated first, so the compiler tries to apply ^ to an int and a boolean and reports *bad operand types for binary operator '^'*. The same applies to & and | in conditions.

5 ^ 5 == 0 what you wrote: 5 ^(5 == 0) what the parser sees:(5 ^ 5) == 0 so 5 == 0 is evaluated first, producing a boolean, and then the compiler tries to XOR an int with a boolean -> error

In a flag test always write the parentheses explicitly, since it is the correct expression anyway and tells the reader exactly what is being checked.

if ((flags & FLAG_READ) != 0) {
    // readable and unambiguous
}

&=, |=, ^=, <<=, >>= and >>>= are the shorthands, and like all compound assignments they insert an implicit narrowing cast.

int n = 12;
n &= 10;
System.out.println(n);
// 8
n = 12;
n |= 1;
System.out.println(n);
// 13
n = 12;
n ^= 5;
System.out.println(n);
// 9
n = 12;
n = 2;
System.out.println(n);
// 3
n = -8;
n >>>= 2;
System.out.println(n);
// 1073741822

This matters on the narrow types, where the written-out form does not compile at all.

byte b = 12;
b &= 10;
// legal, the cast is inserted
System.out.println(b);
// 8
byte c = 12;
c = c & 10;
// error: incompatible types: possible lossy conversion from int to byte

The reason is the promotion rule from the arithmetic topic: b & 10 promotes to int, but b &= 10 narrows back automatically.

Bitwise operators are worth learning properly, but their uses are narrower than they look. The three shifts are the most useful, since << replaces multiplication by a power of two and >>> is how you read the high bits of a packed value. The flag set, test, clear and toggle pattern is the second most useful. Everything else, including the famous XOR swap, is mostly interview material.