Difference between int[] and Integer[]

The substantial difference is that, in JAVA, intit is a primitive type, not an object, whereas it Integeris an object or a Class.

Said in colloquial language: a intis a number, and a Integeris a pointer that refers to a class that contains an integer. Or... more colloquially still: a Integeris a box, and a intis what is inside that box.

What does this mean?

A intis much faster when it comes to calculating numbers in the range -2,147,483,648 [-2 ³¹ ], that is, Integer.MIN_VALUEand +2,147,483,647 [2 ³¹ -1], that is, Integer.MAX_VALUE. In other words, a inthas at our disposal 32 bits of information to be used directly. See specifications .

Variables intare mutable. Unless marked as final, they can change their value at any time. A typical example of using intto change the value of the counter within loops for, while, etc.

A Integer, is an object that contains a single field int. A Integeris much bulkier than a int. Objects Integerare immutable. If you want to affect the value of a variable Integer, the only way is to create a new object Integerand discard the old one.

A. The primitive int

Variables of type int store the actual binary value for the integer they represent.

Therefore, the following code is wrong in Java:

int.parseInt("1");

because intit has no methods, it can only be declared to store a value.

B. The Class Integer

Integer, as I said, is a Class, like any other Java class, with its methods.

This code is correct in Java:

Integer.parseInt ("1");

This is a call to the static method parseIntof the class Integer, which returns a int, not a Integer.

We could say that it Integeris a class with a single field of type int. This class is used where a is needed intto be treated like any other object, such as in generic types or situations where null values ​​are needed.

Here is a small table with some indicators:

| Uso                                                         | int | Integer |
|-------------------------------------------------------------|-----|---------|
| Cálculos con + - * / % ^ etc.                               | sí  | no      |
| Pasar como parámetro                                        | sí  | sí      |
| Retornar como un valor                                      | sí  | sí      |
| Usar métodos desde java.lang.Integer                        | no  | sí      |
| Almacenarlo en un Vector o en otra Colección                | no  | sí      |
| Usarlo como una llave de HashMap                            | no  | sí      |
| Serializarlo                                                | no  | sí      |
| Pasarlo como un objeto genérico (TableCellRenderer)         | no  | sí      |
| Admitir como un valor nulo para significar que no hay valor | no  | sí      |
| Enviarse a sí mismo por RMI (Remote Method Invocation)      | no  | sí      |
| Enviarlo como parte de otro Objeto a través de RMI          | sí  | sí      |

EDIT: Autoboxing and UnBoxing

Not all that glitters is gold, watch out!

Since the indications of the previous table were questioned by @LuiggiMendoza in the comments, I wanted to add this section because it can spread a false concept about the use of autoboxing and unboxing

Since Java 1.5 it is allowed to convert primitives to objects (wrappers) or vice versa automatically. This is known as AutoBoxing and UnBoxing.

Much of what follows is taken from the Java documentation :

A. Autoboxing

Autoboxing is the automatic conversion that the Java compiler does between primitive types and their corresponding object container classes. For example, convert a intto a Integer, a doubleto a Duoble, and so on. If the conversion is done in another way, it is called unboxing.

The Java compiler applies autoboxing when a primitive value is:

• Passed as a parameter to a method that expects an object of the corresponding container class.
• Assigned to a variable of the corresponding container class.

Here is the simplest example of autoboxing:

Character ch = 'a';

The rest of the examples in this section use generics...

Let's consider the following code:

List<Integer> li = new ArrayList<>();
for (int i = 1; i < 50; i += 2)
     li.add(i);

Although lithe values ​​are added intas primitive types, rather than Integer objects, the code is compiled. Because liit is a list of objects Integer, not a list of values int. One may wonder why the Java compiler does not throw an error at compile time . The compiler does not generate an error because it creates an object Integerfrom iand adds the object toli . Therefore, the compiler converts the above code to the following at run time:

List<Integer> li = new ArrayList<>();
for (int i = 1; i < 50; i += 2)
    li.add(Integer.valueOf(i));

In other words, the compiler has to do additional work that the programmer should have done when sending the data of the correct type. Moreover, we could say that the compiler corrects a bug that we have sent to it.

Some consider autoboxing - unboxing to be something magical, something great. Personally, I think it is not. And here it is worth asking, why delegate things to the compiler that the programmer can do? Be careful, because we could have a beautiful code, pleasant to read, but it could have a serious bug at any time.

That would suffice but... on top of that, the inappropriate use of autoboxing-unboxing would have a performance cost that may be slight for small operations, but could be the consequence of an error in the execution of the program without thinking about operations that have to handle large amounts of data or on devices with low memory capacity.

This, among other things, is clearly stated in the Java documentation :

A boxing conversion may result in an OutOfMemoryError if a new instance of one of the wrapper classes (Boolean, Byte, Character, Short, Integer, Long, Float, or Double) needs to be allocated and insufficient storage is available.

B.Unboxing

Converting an object from a container type ( Integer) to its corresponding primitive value ( int) is called unboxing.

The Java compiler applies unboxing when an object of a wrapper class is:

• Passed as a parameter to a method that expects a value of the corresponding primitive type.
• Assigned to a variable of the corresponding primitive type.

Let's consider the following method:

public static int sumEven(List<Integer> li) {
    int sum = 0;
    for (Integer i: li)
        if (i % 2 == 0)
            sum += i;
        return sum;
}

Since the (%) and (+ =) operators do not apply to objects Integer, one might wonder why the Java compiler compiles the method without throwing an error. The compiler does not raise an error because it calls the intValue method to convert a Integerto a intat run time :

Here again we have the compiler doing extra work because the programmer did not use the data type that the element expected.

public static int sumEven(List<Integer> li) {
    int sum = 0;
    for (Integer i : li)
        if (i.intValue() % 2 == 0)
            sum += i.intValue();
        return sum;
}

I ask myself again: why, if the compiler expects a data type, do I have to send it another?

According to Java, it's a matter of aesthetics , not performance:

Autoboxing and unboxing lets developers write cleaner code, making it easier to read.

---

Autoboxing and unboxing allow developers to write clearer code, making it more readable.

That's why Java says:

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.

---

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 numeric values ​​into a collection. It is not appropriate to use autoboxing and unboxing for scientific computing or other performance-sensitive numeric code . An integer is not a substitute for an int; Autoboxing and unboxing blur the distinction between primitive types and reference types, but do not remove it .

(*) Impedance fault (impedance mismatch). To understand this concept I will give an example: If we are expecting values ​​from a column of a database that admits nulls, and we assign that value in a variable of the type, intwe are facing a case of impedance mismatchsince as intit does not admit nulls, the program could give an error , or at most it will assign the value 0instead of NULL. Or vice versa, if we send the values ​​from Java to the DB, if we use a intfor INSERT or UPDATE in the DB, we could be sending the value to some columns instead of NULLthe value 0. This, which may seem silly , could be something very serious in some cases.

In short, don't delegate things to the compiler that you should be doing yourself. The results can be catastrophic. Losing control of the type of data to be used by delegating it is a bad programming practice.

And let's not say anything if we have to make comparisons . We could have unexpected results, since autoboxing - unboxing mask the real values, because a will never Integerbe a substitute for a int. One thing is the box, and another what is inside the box. If we confuse the two things we can make very serious mistakes.

There are more reasons why it is not good to make Java do what one should do. But that would be stretching too far...

It is notable to note that in Java each primitive type has an equivalent wrapper class:

• bytehavebyte
• shorthaveShort
• inthaveInteger
• longhaveLong
• booleanhaveBoolean
• charhaveChar
• floathaveFloat
• doublehaveDouble

First you have to differentiate what is a primitive type and an object.

An object contains attributes and methods. These attributes can be either objects or primitive types.

An object can be assigned null, example:Integer numero = null;

A primitive type contains neither attributes nor methods and represents a minimal unit of expression.

You cannot assign null to a primitive type, example: (compile error)int numero = null;

For your case, int is the primitive type and Integer is the object that represents it.