Primitive types and their sizes

For this lesson, we'll focus on what each primitive can hold, how the bits are laid out (two's complement for integers, IEEE 754 for floating point) and where primitive values actually live in memory. Interviewers ask about this because it looks like trivia but quietly tests whether you understand overflow, precision and memory, the three things behind a surprising number of production bugs.

01Picture it first: the size ladder

Think of primitives as fixed-size boxes on a shelf. Each box has a printed capacity, and the box never stretches: if you pour in more than it holds, the value doesn't spill over into a bigger box, it wraps around (integers) or loses precision (floating point).

Fig. 1

The eight primitives drawn as rows of bytes: byte 1, short and char 2, int and float 4, long and double 8, boolean JVM-dependent

Here's the full table. You don't need every digit memorised, but you should know the sizes cold and the int and long limits roughly ("about 2.1 billion" and "about 9.2 quintillion").

Notice two things. char is the only unsigned integral type, which is why it can't hold -1. And float has the same 32 bits as int but a far larger range, because it trades exactness for reach: past 2²⁴ (16,777,216) it can no longer represent every whole number.

02Integers are two's complement, so they wrap

All four signed integer types (byte, short, int, long) store values in two's complement. The trick is that the top bit has a negative weight. In a byte, the bits are worth -128, 64, 32, 16, 8, 4, 2, 1. So 0111 1111 is 127, and adding one carries into the top bit and gives 1000 0000, which is -128.

Fig. 2

A byte in two's complement: the top bit weighs -128, so 127 plus 1 carries into the sign bit and becomes -128

System.out.println(Integer.MAX_VALUE + 1);        // ?
System.out.println(Math.abs(Integer.MIN_VALUE));  // ?
byte b = 127;
b++;
System.out.println(b);                            // ?
System.out.println(Math.addExact(Integer.MAX_VALUE, 1)); // ?

Here's what you get:

-2147483648
-2147483648
-128
Exception in thread "main" java.lang.ArithmeticException: integer overflow

Notice three things:

1. Integer overflow is silent. No exception, no warning, just a wrapped value. The JLS defines it this way on purpose, because the hardware does it for free.
2. Math.abs(Integer.MIN_VALUE) is still negative. There's no +2,147,483,648 in an int, so negating the minimum gives the minimum back. Use Math.absExact (Java 15+) if that matters.
3. Math.addExact, subtractExact, multiplyExact, incrementExact, negateExact and toIntExact throw ArithmeticException on overflow. They're intrinsified by the JIT, so the cost is a single overflow-flag check.

One more consequence of two's complement: dividing integers by zero is an error (ArithmeticException: / by zero), because there's no bit pattern that means "infinity" in an int. Floating point is different.

03Floating point is IEEE 754 binary

float and double follow IEEE 754: a sign bit, an exponent and a fraction (8 + 23 bits for float, 11 + 52 for double). The fraction is binary, and most decimal fractions have no exact binary form, the same way 1/3 has no exact decimal form. So 0.1 is stored as the closest representable double, which is very slightly more than 0.1.

System.out.println(0.1 + 0.2);                 // ?
System.out.println(0.1 + 0.2 == 0.3);          // ?
double nan = 0.0 / 0;
System.out.println(nan == nan);                // ?
System.out.println(Double.valueOf(nan).equals(nan)); // ?
System.out.println(0.0 == -0.0);               // ?
System.out.println(1 / -0.0);                  // ?
System.out.println(Double.compare(0.0, -0.0)); // ?

0.30000000000000004
false
false
true
true
-Infinity
1

Each line teaches one rule:

• Rounding error is normal. Compare doubles with a tolerance (Math.abs(a - b) < 1e-9) or use BigDecimal when you need exact decimal arithmetic.
• NaN is not equal to anything, including itself. == follows IEEE 754, so nan == nan is false. Test with Double.isNaN(x). But Double.equals and Double.compare treat all NaNs as equal, so NaN works as a HashMap key.
• There are two zeros. 0.0 == -0.0 is true, yet 1 / -0.0 is -Infinity, and Double.compare (plus equals) says they differ. That's why Math.min(0.0, -0.0) carefully returns -0.0.
• Floating-point division by zero doesn't throw. 1.0 / 0 is Infinity, 0.0 / 0 is NaN.

04char is a UTF-16 code unit, not a character

A char is a 16-bit unsigned integer that holds one UTF-16 code unit. For most text, one code unit is one character, so 'A' is 65 and (char) ('A' + 1) is 'B'. But Unicode has more than 65,536 code points. Anything outside the Basic Multilingual Plane, like most emoji, takes two chars (a surrogate pair).

String s = "😀";
System.out.println(s.length());                       // 2  (UTF-16 code units)
System.out.println(s.codePointCount(0, s.length()));  // 1  (actual code points)
System.out.println('A' + 'B');                        // 131 (char + char is int arithmetic)
System.out.println("" + 'A' + 'B');                   // AB

So charAt(i) can hand you half an emoji. If you're processing user text (names, chat messages), iterate with codePoints() instead of charAt.

05boolean: the size the spec won't give you

The Java Language Specification defines boolean by its values, true and false, and deliberately doesn't give it a size. The JVM specification fills in a few details: there are almost no bytecode instructions for boolean, so locals and operands are treated as int (0 or 1), and boolean[] arrays use the same byte-array instructions as byte[].

In practice, on HotSpot:

• a boolean field takes 1 byte in the object layout;
• a boolean[] element takes 1 byte (not 1 bit);
• a boolean local variable occupies a full 32-bit slot in the frame, like an int.

If an interviewer asks "how big is a boolean?", the right answer is "it's JVM-dependent; on HotSpot it's 1 byte in fields and arrays and an int-sized slot as a local". If you need dense bits, use java.util.BitSet, which packs 64 flags into each long.

06Where primitives live: stack vs heap

Here's a common half-truth: "primitives live on the stack, objects live on the heap". The accurate version depends on where the variable is declared, not on its type.

class Order {
    long id;          // field: stored inside each Order object, on the heap
    int quantity;     // field: also on the heap, inside the object

    long total(int price) {           // parameter: a slot in the stack frame
        int qty = quantity;           // local: a slot in the stack frame
        long sum = (long) qty * price; // local long: takes two slots
        return sum;
    }
}

• Local variables and parameters of primitive type live in the method's frame, in the local variable array. int, float and references take one slot; long and double take two. When the method returns, the frame is gone.
• Fields live wherever their object lives, which is the heap. An int field inside an Order is 4 bytes inside that object.
• Array elements are always on the heap, because arrays are objects: an int[1000] is about 4 KB plus a 16-byte header.
• Static fields live with the class's static storage, which in HotSpot is also the heap (they sit in the class's java.lang.Class mirror object).

07Real world: where these limits bite

A few defaults I'd recommend:

Start with int and double for everyday maths, long for anything that counts or measures time, and only reach for the small types when you're storing millions of values.

08How to say it in the interview

When I ask about primitive types, I'm not checking whether you can recite eight names. I'm listening for three things: do you know overflow is silent, do you know why 0.1 + 0.2 != 0.3, and can you say where a primitive lives without falling back on "primitives go on the stack".

Here's how this might look if you sketch it on the whiteboard: