Autoboxing: So I can write: Integer i = 0; instead

问题:

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?

回答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

回答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)

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

回答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.

回答5:

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

回答6:

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

回答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.

回答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.

回答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.