Java "Bit Shifting" Tutorial

Java Bit Shifting Tutorial?

Well, the official Java tutorial Bitwise and Bit Shift Operators covers the actual operations that are available in Java, and how to invoke them.

If you're wondering "what can I do with bit-shifting", then that's not Java specific, and since it's a low-level technique I'm not aware of any list of "cool things you can" do per se. It'd be worth becoming familiar with the definitions, and keeping your eyes open for other code where this is used, to see what they've done.

Note that often bit-twiddling is an efficiency gain at the expense of clarity. For example, a << 1 is usually the same as a * 2 but arguably less clear. Repeated XORs can swap two numbers without using a temporary variable, but it's generally considered better form to write the code more clearly with the temporary variable (or even better, in a utility method). So in this respect it's hard to give great examples, because you're not likely to achieve anything new or profound on an architecture level; it's all about the low-level details. (And I'd estimate that a vast number of uses of bit-twiddling "in the wild" are instances of premature optimisation.)

How does bitshifting work in Java?

Firstly, you can not shift a byte in java, you can only shift an int or a long. So the byte will undergo promotion first, e.g.

00101011 -> 00000000000000000000000000101011

or

11010100 -> 11111111111111111111111111010100

Now, x >> N means (if you view it as a string of binary digits):

• The rightmost N bits are discarded
• The leftmost bit is replicated as many times as necessary to pad the result to the original size (32 or 64 bits), e.g.

00000000000000000000000000101011 >> 2 -> 00000000000000000000000000001010

11111111111111111111111111010100 >> 2 -> 11111111111111111111111111110101

Bit shifting in Java

Because arithmetic operations on shorts yield ints, unless you cast them back down. For example,

short value = 2;
short result = value << 31;

gives you a compile error that you need to cast it down to a short.

This is for a couple reasons, most notably

• the bytecode language doesn't really deal with any types smaller than int
• otherwise operations on shorts overflow much more often.
• to better model most hardware, which usually doesn't do operations on sub-32-bit values

What are bitwise shift (bit-shift) operators and how do they work?

The bit shifting operators do exactly what their name implies. They shift bits. Here's a brief (or not-so-brief) introduction to the different shift operators.

The Operators

• >> is the arithmetic (or signed) right shift operator.
• >>> is the logical (or unsigned) right shift operator.
• << is the left shift operator, and meets the needs of both logical and arithmetic shifts.

All of these operators can be applied to integer values (int, long, possibly short and byte or char). In some languages, applying the shift operators to any datatype smaller than int automatically resizes the operand to be an int.

Note that <<< is not an operator, because it would be redundant.

Also note that C and C++ do not distinguish between the right shift operators. They provide only the >> operator, and the right-shifting behavior is implementation defined for signed types. The rest of the answer uses the C# / Java operators.

(In all mainstream C and C++ implementations including GCC and Clang/LLVM, >> on signed types is arithmetic. Some code assumes this, but it isn't something the standard guarantees. It's not undefined, though; the standard requires implementations to define it one way or another. However, left shifts of negative signed numbers is undefined behaviour (signed integer overflow). So unless you need arithmetic right shift, it's usually a good idea to do your bit-shifting with unsigned types.)

---

Left shift (<<)

Integers are stored, in memory, as a series of bits. For example, the number 6 stored as a 32-bit int would be:

00000000 00000000 00000000 00000110

Shifting this bit pattern to the left one position (6 << 1) would result in the number 12:

00000000 00000000 00000000 00001100

As you can see, the digits have shifted to the left by one position, and the last digit on the right is filled with a zero. You might also note that shifting left is equivalent to multiplication by powers of 2. So 6 << 1 is equivalent to 6 * 2, and 6 << 3 is equivalent to 6 * 8. A good optimizing compiler will replace multiplications with shifts when possible.

Non-circular shifting

Please note that these are not circular shifts. Shifting this value to the left by one position (3,758,096,384 << 1):

11100000 00000000 00000000 00000000

results in 3,221,225,472:

11000000 00000000 00000000 00000000

The digit that gets shifted "off the end" is lost. It does not wrap around.

---

Logical right shift (>>>)

A logical right shift is the converse to the left shift. Rather than moving bits to the left, they simply move to the right. For example, shifting the number 12:

00000000 00000000 00000000 00001100

to the right by one position (12 >>> 1) will get back our original 6:

00000000 00000000 00000000 00000110

So we see that shifting to the right is equivalent to division by powers of 2.

Lost bits are gone

However, a shift cannot reclaim "lost" bits. For example, if we shift this pattern:

00111000 00000000 00000000 00000110

to the left 4 positions (939,524,102 << 4), we get 2,147,483,744:

10000000 00000000 00000000 01100000

and then shifting back ((939,524,102 << 4) >>> 4) we get 134,217,734:

00001000 00000000 00000000 00000110

We cannot get back our original value once we have lost bits.

---

Arithmetic right shift (>>)

The arithmetic right shift is exactly like the logical right shift, except instead of padding with zero, it pads with the most significant bit. This is because the most significant bit is the sign bit, or the bit that distinguishes positive and negative numbers. By padding with the most significant bit, the arithmetic right shift is sign-preserving.

For example, if we interpret this bit pattern as a negative number:

10000000 00000000 00000000 01100000

we have the number -2,147,483,552. Shifting this to the right 4 positions with the arithmetic shift (-2,147,483,552 >> 4) would give us:

11111000 00000000 00000000 00000110

or the number -134,217,722.

So we see that we have preserved the sign of our negative numbers by using the arithmetic right shift, rather than the logical right shift. And once again, we see that we are performing division by powers of 2.

Bitshifting a long in Java

It's because 1 is an int literal, so << is applied to an integer. The result is cast to a long, but by then it's too late.

If you write 1L << 32, etc., then all will be well. L is used to denote a long literal.

How, exactly, do bitwise operators work in Java?

The bitwise operators work exactly as you would expect. They are strict bit-operators and do not consider semantics of bits at all.

Sometimes it is easiest to run through code using breakpoints. For your specific example, I converted the steps of the operation into atomic statements and printed the results with Long.toString.

int x = -57;

// step 1:
long xCast = (long) x;
System.out.println(Long.toString(xCast, 2)); // -1110011 - this is not the bitwise representation however.

long mask = 0xffffffffL;
System.out.println(Long.toString(mask, 2)); // 11111111111111111111111111111111

// step 2:
long result = ((long) x) & mask;
System.out.println(Long.toString(result, 2)); // 11111111111111111111111111000111

Step 1 is the primary reason the operation looks as it does. In Java, all (strictily numeric) values are signed (chars are unsigned). This means that, as you correctly stated, all highest bits are sign-bits. However the interesting part is what the rest of the bits do, if a number is negative.
The following thread already covered the basics of the 'Two's complement':
What is “2's Complement”?
So does this wikipedia-page: https://en.wikipedia.org/wiki/Two%27s_complement

To make it short, in java, for integers:

int zero = 0; // == 0b00000000_00000000_00000000_00000000

int maxPositive = Integer.MAX_VALUE; // == 0b01111111_11111111_11111111_11111111

int minus1 = -1; // == 0b11111111_11111111_11111111_11111111

int minNegative = Integer.MIN_VALUE; // == 0b10000000_00000000_00000000_00000000

So the reason everything works out is because if the integer is negative, when it is cast, the entire upper 32 bits are converted to 1s, because otherwise the represented value of the number would change. effectively:

int x = 0b11111111_11111111_11111111_11000111;

is cast to:

long xCast = 0b11111111_11111111_11111111_11111111_11111111_11111111_11111111_11000111;

Because you as the developer expect the method to return only the initially set bits, you have to mask the upper bits out of the result. This is done in step 2.

So the answer to your example: The representation of non-floating values in Java are two's complement, and therefore, when smart-casting a value from int to long, the upper bits are filled up with 1s for negative numbers. Thus they have to be removed.

Java: right shift on negative number

Because in Java there are no unsigned datatypes, there are two types of right shifts: arithmetic shift >> and logical shift >>>. http://docs.oracle.com/javase/tutorial/java/nutsandbolts/op3.html

Arithmetic shift >> will keep the sign bit.

Unsigned shift >>> will not keep the sign bit (thus filling 0s).

(images from Wikipedia)

---

By the way, both arithmetic left shift and logical left shift have the same result, so there is only one left shift <<.

---

Related Topics