Effective Java 49 Prefer primitive types to boxed primitives

No.	Primitives	Boxed Primitives
1	Have their own values	Have identities distinct from their values
2	Have only fully functional values	Have one nonfunctional value which is null
3	Time and space efficient	Time and space inefficient

   

Note

• Applying the ==operator to boxed primitives is almost always wrong.

  Comparator<Integer> naturalOrder = new Comparator<Integer>() {

  public int compare(Integer first, Integer second) {

  int f = first; // Auto-unboxing

  int s = second; // Auto-unboxing

  return f < s ? -1 : (f == s ? 0 : 1); // No unboxing

  }

  };

     

• When you mix primitives and boxed primitives in a single operation, the boxed primitive is auto unboxed.

  public class Unbelievable {

  static Integer i;

  public static void main(String[] args) {

  if (i == 42) // This will invoke an auto-unboxed, since the i is null so there will be a NullPointerException.

  // Fixing the program is as simple as declaring i to be an int instead of an Integer.

  System.out.println("Unbelievable");

  }

  }

     

• Repeatedly boxed and unboxed will cause the observed performance degradation.

  // This program is much slower than it should be because it accidentally declares a

  // local variable (sum) to be of the boxed primitive type Long instead of the primitive type long.

  public static void main(String[] args) {

  Long sum = 0L;

  for (long i = 0; i < Integer.MAX_VALUE; i++) {

  sum += i;

  }

  System.out.println(sum);

  }

     

  Scenario of using boxed primitives

  • As elements, keys and values in collections since you can't put primitives in collections.
  • As type parameters in parameterized types.(eg.ThreadLocal<Integer>).
  • Making reflective method invocations(Item 53).

     

  Summary

  Use primitives in preference to boxed primitives whenever you have the choice. Primitive types are simpler and faster. Autoboxing reduces the verbosity, but not the danger, of using boxed primitives. When your program compares two boxed primitives with the ==operator, it does an identity comparison, which is almost certainly not what you want. When your program does mixed-type computations involving boxed and unboxed primitives, it does unboxing, and when your program does unboxing, it can throw a NullPointerException. Finally, when your program boxes primitive values, it can result in costly and unnecessary object creations.