Why Java Wrapper Classes Can Kill Performance and Trigger NPEs

1. Equality vs Inequality? The Problem

Code examples show that using == on wrapper objects compares references, while Integer.valueOf caches values between -128 and 127, making == return true for those values but false outside the range.

class Biziclop {
    public static void main(String[] args) {
        System.out.println(new Integer(5) == new Integer(5)); // false
        System.out.println(new Integer(500) == new Integer(500)); // false
        System.out.println(Integer.valueOf(5) == Integer.valueOf(5)); // true
        System.out.println(Integer.valueOf(500) == Integer.valueOf(500)); // false
    }
}

When the second and third statements return false, it is because each new Integer creates a distinct object on the heap. The third statement returns true because the JVM reuses cached objects for the range -128 to 127.

2. Poor Performance

Using wrapper types in tight loops creates many temporary objects. The following benchmark from Effective Java demonstrates that summing with a Long object is about six times slower than using a primitive long:

public static void main(String[] args) {
    Long sum = 0L; // uses Long, not long
    for (long i = 0; i <= Integer.MAX_VALUE; i++) {
        sum += i;
    }
    System.out.println(sum);
}

The overhead comes from heap allocation, initialization, and unboxing. Joshua Bloch advises to avoid creating unnecessary objects.

3. Hidden NullPointerExceptions

Wrapper objects can be null. Unboxing a null wrapper throws an NPE at runtime, as shown below:

Integer in = null;
int i = in; // NPE at runtime

Even the ternary operator can introduce NPEs because the compiler may unbox a wrapper when the other operand is a primitive. The Java Language Specification states:

If one operand of the ternary operator is a primitive type T and the other is the corresponding wrapper type, the result type is the primitive T .

This rule causes the following code to throw an NPE:

class Biziclop {
    public static void main(String[] args) {
        Boolean b = true ? returnsNull() : false; // NPE on this line
        System.out.println(b);
    }
    public static Boolean returnsNull() {
        return null;
    }
}

4. Confusing API Design

The Long.getLong(String) method is often mistaken for Long.valueOf or Long.parseLong. It actually reads a system property and returns a Long object, or null if the property is missing or not a valid number:

class Biziclop {
    public static void main(String[] args) {
        System.setProperty("22", "22");
        System.setProperty("23", "hello world!");
        System.out.println(Long.getLong("22")); // 22
        System.out.println(Long.getLong("23")); // null
        System.out.println(Long.getLong("24")); // null
    }
}

Misusing this API leads to unexpected null results.

5. Best Practices

According to the Alibaba Java Programming Manual, follow these three recommendations when using wrapper classes:

Use wrapper types for POJO fields.

Use wrapper types for RPC method parameters and return values.

Prefer primitive types for local variables.

These guidelines help avoid accidental NPEs and make the intent of nullable values explicit.