Take the 2-minute tour ×

Autoboxing seems to come down to the fact that I can write:

Integer i = 0;

instead of:

Integer i = new Integer(0);

So, the compiler can automatically convert a primitive to an Object.

Is that the idea? Why is this important?

share|improve this question

9 Answers 9

up vote 12 down vote accepted

You kind of simplified it a little too much.

Autoboxing also comes into play when using collections. As explained in sun's java docs:

Collections can only hold object references, so you have to box primitive values into the appropriate wrapper class. ... When you take the object out of the collection, you get the Integer that you put in; if you need an int, you must unbox the Integer using the intValue method. All of this boxing and unboxing is a pain, and clutters up your code. The autoboxing and unboxing feature automates the process, eliminating the pain and the clutter.

So when should you use autoboxing and unboxing? Use them only when there is an “impedance mismatch” between reference types and primitives, for example, when you have to put numerical values into a collection. It is not appropriate to use autoboxing and unboxing for scientific computing, or other performance-sensitive numerical code. An Integer is not a substitute for an int; autoboxing and unboxing blur the distinction between primitive types and reference types, but they do not eliminate it.

Great overview of Autoboxing

share|improve this answer


Integer i = 0;

is equivalent to

Integer i = Integer.valueOf(0);

The distinction is that valueOf() does not create a new object for values between -128 and 127 (Apparently this will be tunable if Java 6u14)

share|improve this answer
Thank you! Was very confused why only sometimes a new object was created! –  DustByte Mar 20 at 14:27
@DustByte because it can only cache the common objects. Caching every Integer would use 40 GB of memory (just for Integers) –  Peter Lawrey Mar 23 at 7:30

That is the idea, yes. It's even more convenient to be able to assign an Integer to an int, though.

One could argue that autoboxing addresses a symptom rather than a cause. The real source of confusion is that Java's type system is inconsistent: the need for both primitives and object references is artificial and awkward. Autoboxing mitigates that somewhat.

share|improve this answer
What's awkward about having primitives? You mean it detracts from the purely Object Oriented nature of the language? In Ruby for example even integers are objects. Is that what you mean? –  Harry Quince Apr 20 '09 at 0:27
I really don't see why it's such a big deal. I think they should have left well enough alone. This doesn't seem to add much, from what I can tell so far. Of course, I just learned about this feature about five minutes ago. –  Harry Quince Apr 20 '09 at 0:28
Yes, that's what I mean. I'm not an OO purist by any stretch, but it's not obvious why a programmer benefits from having both an int and an Integer at their disposal. I think one abstraction should be enough to cover "integer-ness". –  jcrossley3 Apr 20 '09 at 0:36
You sound like an OO purist to me. –  Harry Quince Apr 20 '09 at 0:38
Thanks, I guess. But remember: you MAY choose not to autobox in Java, but you MUST choose whether to use an int or an Integer to represent a whole number. If that seems "well enough" to you, fine. Otherwise, autobox away! –  jcrossley3 Apr 20 '09 at 1:03

It exists so that you can write code like

List<Integer> is = new ArrayList<Integer>();
is.add(1); // auto-boxing

int sum = 0;
for (int i : is)  // auto-unboxing
    sum += i;

For single integers you should by default use the type int, not Integer. Integer is mostly for use in collections.

Beware that a Long is different from the same value as an Integer (using equals()), but as a long it is equal to an int (using ==).

share|improve this answer

Makes for more readable and neater code. Especially if you're doing operations (Since Java doesn't have operator overloading).

share|improve this answer

With my cynical hat on: to make-up for limitations on the original Java (I mean Oak here) spec. Not just the first time.

share|improve this answer
Which limitations? –  Harry Quince Apr 20 '09 at 0:22
Where to start? The Time-Date API, the lack of a Collections API from the start, arrays being "light" Objects and not overriding Object.equals(), the lack of Generics from the start, the "weird" cloning mechanism... You eventually find subtle creaks in the language, or read of them and how they were patched. At the end of the day, Java was a revived embedded language for the dot-com boom, and it shows. I prefer C#, despite being Microsoft's. –  Humphrey Bogart Apr 20 '09 at 0:35

From what I remember from reading Joshua Bloch's Effective Java, you should consider the primitives over their boxed counterparts. Autoboxing without regard for its side effects can produce problems.

share|improve this answer
What do you mean? –  Harry Quince Apr 20 '09 at 0:29
Because primitives are always copied when they are passed. I do not believe this to be true of their boxed counterparts. –  CookieOfFortune Apr 20 '09 at 0:48

Adding to Lim's comment, primitives are stored on the stack, and primitive-wrappers, as objects, are stored on the heap... There are subtle implications due to this.

share|improve this answer

The main advantage would be readability, syntactic sugar basically. Java is already very verbose, Sun is trying all sorts of ways to make the syntax shorter.

share|improve this answer

Your Answer


