skip to content

What is the difference between Integer.parseInt("42") and Integer.valueOf("42")?

level: middleimportance: must knowfreq 75%

answer

  1. parseInt → primitive int
  2. valueOf → Integer object (+ cache -128..127)
  3. Both throw NumberFormatException
  4. valueOf = parseInt then box
  5. valueOf replaces deprecated new Integer(...)

basics

~10 s

parseInt returns a primitive int. valueOf returns an Integer object (a wrapper). Both parse the text the same way, but you get different return types.

solid answer

~40 s

Both take a String and convert it to a number, throwing NumberFormatException on bad input. The key difference is the return type: Integer.parseInt("42") returns a primitive int, while Integer.valueOf("42") returns an Integer wrapper object. Internally valueOf parses the text and then boxes the result, and crucially it consults an integer cache for values in the range -128..127, returning a shared instance instead of a new object. So prefer parseInt when you just need the numeric value (no boxing), and valueOf when you actually need an Integer object — for example to put it in a collection. The matching pattern exists across wrappers: Long.parseLong/valueOf, Double.parseDouble/valueOf, etc. valueOf is also the modern, recommended replacement for the deprecated new Integer(...) constructor.

code

java · 9 lines
java
int n = Integer.parseInt("42");        // primitive int, no allocation
Integer boxed = Integer.valueOf("42");  // Integer object

// Both throw NumberFormatException on bad input:
// Integer.parseInt("abc");  ->  java.lang.NumberFormatException

// Integer cache (-128..127) makes == unreliable for wrappers:
System.out.println(Integer.valueOf(100) == Integer.valueOf(100)); // true (cached)
System.out.println(Integer.valueOf(1000) == Integer.valueOf(1000)); // false (two objects)

go deeper

for a junior

Knows parseInt gives an int and valueOf gives an Integer, and that bad input throws an error.

for a middle

Explains the return-type/boxing difference, the shared NumberFormatException, and when to choose each.

for a senior

Connects valueOf to the Integer cache, autoboxing, == pitfalls, and the deprecated constructor.

for a principal

Discusses allocation/GC impact of boxing on hot paths and how the spec-mandated cache range and JIT escape analysis interact at scale.

## The two methods Every numeric wrapper class offers a `parseXxx` static method and a `valueOf` static method that both convert a `String` into a number. - `int Integer.parseInt(String s)` → returns a **primitive** `int`. - `Integer Integer.valueOf(String s)` → returns an **Integer object** (a wrapper). The family is consistent: `Long.parseLong`/`Long.valueOf`, `Double.parseDouble`/`Double.valueOf`, `Boolean.parseBoolean`/`Boolean.valueOf`, and so on. ## What they share Both interpret the same string format and both throw a **`NumberFormatException`** (an unchecked `RuntimeException`) if the string is not a valid number (e.g. `"abc"`, an empty string, or out-of-range value). In fact `valueOf(String)` is essentially implemented as `Integer.valueOf(Integer.parseInt(s))` — it parses with `parseInt` and then boxes the result. ## The core difference: return type and boxing `parseInt` hands you the bare numeric value with **no object allocated**. `valueOf` hands you a wrapper **object**. That object creation is where the **Integer cache** matters: `Integer.valueOf` is required by the spec to return cached, shared instances for values in the range **-128 to 127** (and the cache for other wrapper types similarly). For those small values, two calls to `valueOf(100)` return the *same* object reference; outside the range each call creates a new object. ```java int a = Integer.parseInt("42"); // primitive, no allocation Integer b = Integer.valueOf("42"); // wrapper object, may be cached ``` ## Why this matters in practice - If you only need the **number** (arithmetic, an index, a loop bound), use `parseInt` — it avoids creating a throwaway object. - If you need an **Integer** (to store in a `List<Integer>`, use as a map key, or pass where an object is expected), use `valueOf` so you get caching for small values instead of always allocating. - Because of the cache, comparing wrappers with `==` is a trap: `Integer.valueOf(100) == Integer.valueOf(100)` is `true` (cached) but `Integer.valueOf(1000) == Integer.valueOf(1000)` is `false` (two objects). Always compare wrapper values with `.equals()` or by unboxing. ## Relationship to autoboxing and the deprecated constructor Autoboxing (`Integer x = 5;`) uses `Integer.valueOf` under the hood, so it also benefits from the cache. The old `new Integer("42")` constructor is **deprecated since Java 9**: it always allocates a fresh object and never caches, so `valueOf` is the preferred way to obtain an `Integer`. ## Quick rule **Need a value → `parseInt`. Need an object → `valueOf` (never `new Integer`).**

  • What exception is thrown for Integer.parseInt("abc") and is it checked?
    NumberFormatException — an unchecked RuntimeException, so the compiler does not force you to catch it.
  • Why can Integer.valueOf be more memory-efficient than new Integer?
    valueOf reuses cached shared instances for the range -128..127 instead of allocating a new object each time; the constructor always allocates.

saying these in an interview costs you the question

  • Saying parseInt returns an Integer — it returns a primitive int
  • Claiming valueOf and parseInt parse differently — the parsing logic is identical; only the return type/boxing differs
  • Recommending new Integer(...) — it is deprecated since Java 9
  • Believing valueOf always returns a brand-new object — small values are cached

context

resolving links…