Autoboxing: So I can write: Integer i = 0; instead of: Integer i = new Integer(0);

Question

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?

Stickweed

Answer 1

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

Teamwork

Answer 2

BTW

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)

Mandeville

Thank you! Was very confused why only sometimes a new object was created! – Breedlove

@Breedlove because it can only cache the common objects. Caching every Integer would use 40 GB of memory (just for Integers) – Mandeville

Answer 3

It exists so that you can write code like

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

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 ==).

Shortcircuit

Answer 4

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.

Transaction

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? – Stickweed

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. – Stickweed

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". – Transaction

You sound like an OO purist to me. – Stickweed

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! – Transaction

Answer 5

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

Unspoken

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. – Unspoken

Answer 6

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

Sora

Answer 7

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.

Planetoid

Because primitives are always copied when they are passed. I do not believe this to be true of their boxed counterparts. – Sora

Answer 8

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.

Unspoken

Answer 9

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.

Oza