Types, Variables and Wrappers

Why this matters

• The == versus .equals() question is the most common source of silent bugs for new Java developers, and autoboxing is why.
• Integer overflow and floating-point imprecision cause money and timing bugs that no test catches unless you know to look.
• Enums replace a whole category of bug-prone integer constants, and most people under-use them.

The eight primitives

Overflow is silent

Arithmetic wraps around rather than failing, which is the single most dangerous default in the language.

int max = Integer.MAX_VALUE;        // 2_147_483_647
System.out.println(max + 1);        // -2147483648 — wrapped, no warning

long millisPerDay = 24 * 60 * 60 * 1000;          // fine
long millisPerYear = 24 * 60 * 60 * 1000 * 365;   // wrong: int overflow before assignment
long correct = 24L * 60 * 60 * 1000 * 365;        // one L fixes the whole expression

The third line is the classic trap. Every operand is an int, so the multiplication happens in 32 bits and overflows before the result is widened to long. Marking the first operand L forces the whole expression into 64-bit arithmetic.

Floating point is approximate

System.out.println(0.1 + 0.2);              // 0.30000000000000004
System.out.println(0.1 + 0.2 == 0.3);       // false

// For money, use BigDecimal — and the String constructor, not the double one
BigDecimal a = new BigDecimal("0.1");
BigDecimal b = new BigDecimal("0.2");
System.out.println(a.add(b));               // 0.3

double stores binary fractions, and 0.1 has no exact binary representation, just as 1/3 has no exact decimal one. Never use double for currency. Either use BigDecimal constructed from strings, or store whole cents in a long.

Wrappers and autoboxing

Each primitive has an object counterpart — int/Integer, double/Double and so on — because collections and generics can only hold objects. The compiler converts automatically.

List<Integer> scores = new ArrayList<>();
scores.add(42);              // autoboxing: int → Integer
int first = scores.get(0);   // unboxing: Integer → int

That convenience has three sharp edges.

Integer a = 127, b = 127;
System.out.println(a == b);        // true  — both from the cache

Integer c = 128, d = 128;
System.out.println(c == d);        // false — two distinct objects
System.out.println(c.equals(d));   // true  — compares values

Integer absent = null;
int value = absent;                // NullPointerException on unboxing

Enums instead of constants

An enum is a class with a fixed set of instances. It gives you type safety, readable output, and a natural place to attach behaviour.

public enum Status {
    PENDING("Awaiting review"),
    APPROVED("Ready to ship"),
    REJECTED("Returned to sender");

    private final String description;

    Status(String description) {
        this.description = description;
    }

    public String description() {
        return description;
    }

    public boolean isFinal() {
        return this == APPROVED || this == REJECTED;
    }
}

Operators worth a second look

Common misreadings

• "var makes Java dynamically typed." The type is fixed at compile time; only the writing is shorter.
• "char can be negative." It is the one unsigned primitive, ranging from 0 to 65535.
• "== works for Integer." It works accidentally inside the cache range, which makes the bug worse, not better.
• "float saves meaningful memory." On modern hardware double is the sensible default; float mainly buys imprecision.
• "Local variables default to zero." Fields do. Locals must be assigned before use, enforced at compile time.