What Are the 8 Primitive Data Types in Java?

Java has exactly eight primitives, grouped in three families. The four integer types are byte (8 bits, signed, -128 to 127), short (16 bits, -32768 to 32767), int (32 bits, roughly plus or minus 2.1 billion) and long (64 bits). The two floating point types are float (32 bits) and double (64 bits). The remaining two are char (16 bits, an unsigned UTF-16 code unit) and boolean (1 bit of logical state, although the JVM stores it as a byte in practice).

Default values matter more than most people expect. Every field of a class, and every element of an array, starts at the zero value for its type: 0 for the numeric types, false for boolean, and the null character for char. Local variables are different — they have no default at all, and the compiler refuses to let you read one before you assign it. That asymmetry is deliberate: it removes an entire family of silent-null bugs at the source level.

Two size facts that get asked repeatedly. First, on any Java platform an int is 32 bits and a long is 64 bits, because the Java language specification fixes those widths; the primitive sizes are not chosen to match the underlying CPU. Second, a char is 16 bits because it is a UTF-16 code unit, which is why a supplementary character such as an emoji needs a surrogate pair and therefore two chars — a fact that matters if you are counting characters in user input.

Note also that there is no primitive for decimal money. BigDecimal is a class, and for financial code it is the only correct choice; double and float are binary floating point and cannot represent most decimal fractions exactly.

Instance fields and array elements get the type's zero value automatically: 0 for the numeric types, false for boolean, and the null character for char. A local variable, by contrast, has no default value at all — the compiler rejects any attempt to read it before assignment, which removes a whole category of uninitialised-variable bugs from the language rather than from the code review checklist.

public class Main {
    public static void main(String[] args) {
        // Local variables: no default. The compiler would refuse to read
        // these before assignment, so we give them the type's zero value.
        int count = 0;
        boolean ready = false;
        double ratio = 0.0;
        char initial = (char) 0;

        System.out.println("count   = " + count);
        System.out.println("ready   = " + ready);
        System.out.println("ratio   = " + ratio);
        System.out.println("initial = [" + initial + "] -> unicode " + (int) initial);

        // Fields are different: the JVM supplies the default for you.
        System.out.println("field defaults: " + new Defaults());
    }
}

class Defaults {
    int count;
    boolean ready;
    double ratio;
    char initial;

    @Override
    public String toString() {
        return "count=" + count + " ready=" + ready + " ratio=" + ratio
             + " initialCode=" + (int) initial;
    }
}

The practical consequences are worth spelling out in an interview. A boolean field that you never assign is false, not a validation error — so a valid flag on a form bean silently starts life as false, which is safe. A char field that you never assign is the null character, and printing it produces nothing visible, which is a classic source of mystery output. And a numeric field that you never assign is zero, so a price of zero is not automatically distinguishable from a price nobody set.

Java deliberately omits unsigned primitives. The reason is that unsigned arithmetic changes the meaning of overflow: an int that underflows in a signed calculation wraps to a negative number, while an unsigned one wraps to a large positive number. Language designers found that mixing signed and unsigned arithmetic in the same expression produces a family of subtle bugs that outweigh the benefit of a wider positive range on the most common types. The Java specification settled on fixed-width two's-complement signed types with well-defined wrap-around, plus a small set of library methods that opt into unsigned semantics explicitly.

The workaround is the unsigned-prefixed method family on the boxed numeric classes. Integer and Long expose toUnsignedString, toUnsignedLong, compareUnsigned, divideUnsigned and remainderUnsigned, and Long additionally offers parseUnsignedLong. The parsing method is the important one for reading unsigned data out of a file or a network protocol.

public class Main {
    public static void main(String[] args) {
        int minusOne = -1;
        System.out.println("signed view   : " + minusOne);
        System.out.println("unsigned view : " + Integer.toUnsignedString(minusOne));
        System.out.println("as long       : " + Integer.toUnsignedLong(minusOne));

        String hex = "DEADBEEF";
        long parsed = Long.parseUnsignedLong(hex, 16);
        System.out.println("parsed hex    : " + parsed + " -> 0x" + Long.toHexString(parsed));

        System.out.println("compare uns   : " + Integer.compareUnsigned(minusOne, 1));
        System.out.println("divide uns    : " + Integer.divideUnsigned(minusOne, 2));
    }
}

A second, cleaner option exists for values that genuinely need more range: use a long instead of an int, or BigInteger when the range is unbounded. Many teams that hit unsigned limits in practice conclude they needed a bigger signed type rather than an unsigned one. When you do need genuine unsigned semantics — parsing a raw protocol header, or masking bits out of a hash — the unsigned methods are the documented, safe route.